You are here

Task 1 Tips and Traps

Developing Requirements

During requirements analysis, you should focus on understanding the problem while being careful not to prematurely leap to potential solutions. Focus on “What are the requirements?” and not on “How will they be implemented?”

As you review the detailed output of your work in Software Product Definition, identify additional user goals and develop additional scenarios, as required, to help understand more completely how the user can better perform his or her job

Use your storyboard interviews to validate your previous understanding and to take your dialog with users to the next level of specificity

Your use cases, in turn, will further elaborate and formalize the task-oriented work processes developed in your scenarios and storyboards, including alternative paths and exception handling

Be sure to consider technological risks, business and strategic factors, as well as user/customer needs, when prioritizing requirements; be sure to document these explicitly when you identify them

Employing standard outlines or templates for documenting the requirements accelerates requirements development and improves quality by reminding you of topics that you need to discuss with internal and external stakeholders and eventually to document. That said, be sure that any templates you consider are appropriate to your purposes in this task. (Most tend to be overkill for a project of this magnitude.)

The User Requirements Document

Remember (as Cockburn says) that use cases may suffice to document functional requirements, but these only constitute a fraction of the total requirements that must be collected and documented for a project like this

Prioritize the requirements and document your prioritization scheme to ensure that anyone adding requirements would know how to prioritize theirs appropriately

Review each of your use cases using the errors discussed in Chapter 19 and table 20.1 of Cockburn, pp. 212-213. (Over the years, many teams have failed to perform this step and have turned in flawed use cases that should have been caught during their internal review!)

Organize your document so that someone can find information of interest and also understand how to add to it

Conduct a peer review your work. Always ask if someone can really understand from the document what the system has to do and, thus what must be designed and implemented

The Supplementary Requirements Specification

Don’t simply compile a generic catalog of all possible nonfunctional requirements; think about the ones that matter most to the success of this product

Don’t define nonfunctional requirements in generic terms; define them with respect to this project with special emphasis on how they will be measured (or at least observed) to ensure they have been met. (For example, don’t just say “The product shall be usable.” Instead think about what usability means in the context of this project, with our target users, and define the requirement accordingly.)

Consider using the utility tree and scenarios technique developed by the Software Engineering Institute to identify and define nonfunctional requirements (See the readings for more detail.)

We strongly suggest documenting your nonfunctional requirements in Gilb's PLanguage

Include any global technical requirements (e.g., platform), business rules, general business requirements, et cetera – as appropriate


If your investigation uncovers any risks with respect to providing the appropriate functionality or satisfying key nonfunctional requirements, be sure to surface them in your document in a way that they can be clearly understood.

Requirements Tools

There are numerous tools available for helping with requirements analysis.  The goal of this part of the task is to explore some of the available tools and to identify some that you find useful for carrying out the requirements validation with users and producing the User Requirements Document.  There is no requirement that you use any of these tools in creating your work products.  In many cases, using a tool takes away from the essential analysis of the problem.  "A fool with a tool is still a fool."

You can draw storyboards and other artifacts by hand, including low-resolution screen designs.  The goal is to enhance communication with your potential user.

There are some websites that contain descriptions of specific classes of tools or that contain tools that we believe are worth exploring.  This list is not extensive or conclusive, but is merely intended to get you started.  As you do your evalution, keep in mind that you can often download and use proprietary tools at no charge for 30 days, as long as you are willing to handle the vendor's sales efforts.  Many of these tools are free or open source, which avoids the time limits and sales pressures.

UML tools

Free UML tools (mostly closed source)

What had its origins as Software through Pictures is now Open Ameos


Look at the options at

Also consider

Storyboardthat has a limited free option, but you can also consider paying for 1-2 months.

UI prototyping

Many candidates for different types of interfaces, including those mentioned at

You might try the new version of the free Pencil tool. It supports desktop and web designs, as well as Android and iOS models. Open source from Vietnam.

Requirements management  (aNimble is the successor to OSRMT.)

Various commercial requirements management tools offer short, free trials.


To come ....