• Ferhan Bulca

    I am an executive leader and a serial intrapreneur focused on innovation and design thinking. My purpose in life is to create products and services that make the world a better place to live in.

    In the course of my career, I have developed a deep understanding and expertise on all aspects of technology commercialization and product/service development. As a result, I have built multi-million dollar businesses from the ground up.

    I am the creator and the Lead Instructor for Business Innovation Certificate Program at University of Toronto, School of Continuing Studies.

    I offer business consulting services and I am available as a speaker for private and public events.

    Watch my recent talk at Ashoka Canada's Changemakers event at University of Toronto on YouTube.

  • Consult with me on Maven
  • Enter your email address to follow this blog and receive notifications of new posts by email.

    Join 300 other followers

  • Advertisements

Software Requirements – Four Fundamental Tools

Your product development methodologies may be inspired by waterfall, agile or, most likely, a combination of the two. Whatever your development practices may be, the way requirements are managed plays an important role for the success of your projects. Many organizations and developers consider requirements as written statements. In fact, visual representations of the requirements typically add significant value to the understanding of the product to be developed when little information is known about the required functionalities and features.

Visual representations continue to be useful beyond the confines of one development project and can be helpful in future derivatives by creating a solid baseline for the product.

There are a number of representations to choose from and they all have their value in different situations. Here, we discuss four of them, which are used as the fundamental requirements representations at MDS Sciex (http://www.mdssciex.com/), a division of MDS Analytical Technologies, in the early phases of software product development.

1) Context Diagram: A powerful and simple way to describe the scope of the product to be developed. The diagram clearly shows the context of the product and identifies the interfaces and the interactions of the product with its operational environment.
2) Task Flows: represent the typical and atypical tasks and activities performed by the user who will be using the product. A task flow provides a simple graphical representation of core user requirements for the product by describing how the users perform their everyday tasks, which include the tasks targeted by the product to be developed.
3) Product Navigation Models: show how the product operates. Product Navigation Models are often shown with User Task Flows overlaid, allowing verification of how well they support the Task Flows.
4) High-Level User Interface Design: provides a common, high-level view of what will be built, from the target audience’s perception. This is where we start to introduce more detail compared to the previous three artifacts. Key frames are wire frame drawings of key components of the user interface. A low-fidelity sketch of a user interface component; it includes indication of the type of information shown and main functions available, and shows a potential, general layout. Visual details and secondary functions are either omitted or preliminary.

These artifacts form the foundation of software requirements in an Agile software development environment at MDS Sciex.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: