IT Best PracticesProject Management

A Short Guide to Writing Software Requirements

Requirements writing is critical. Misinterpretations, flawed designs, missing functionality, they all contribute to the ruin of the project and they all stem from shoddy requirements. In his blog post, PJ Srivastava writes about user stories, workflow diagrams, visual designs, nonfunctional requirements, and test scenarios. These are among the tactics a business analyst can use to guard against degenerate requirements.

The Fundamentals

In the world of requirements writing, the language used, the level of detail, and the type of documentation all impact the finished product. (That applies to the requirements document, in addition to the project for which they are written) Myth #1: requirements are static – false. Requirements are emergent, and they evolve with the project:

For any non-trivial project, it’s impossible to imagine the perfect design for something, see every detail, and foresee and account for every technical challenge or situation that might occur along the way.

Design is an ongoing discussion. Not everything can be planned up front with an extended discovery phase to cover all the bases. And change orders happen. That’s life in IT. But to ensure that a project is robust, that it survives to reach the end user, several tactics must be employed by the business analyst.

The Story of Requirements Writing

  • User stories
  • User typing
  • Building a workflow diagram
  • Building wireframes and visual designs
  • Nonfunctional requirements
  • Low-fidelity prototypes
  • Test tables / test scripts

A user story is a lot like a news story. One must answer the questions, “Who wants what and why?”

User Stories facilitate discussion with team members—technical and non-technical—to help plan and understand a project at its basic level.

Different types of users will inevitably interact with one’s design; therefore, it is critical to account for all the user stories one might encounter, whether an administrator, a VIP, registered user, and so on. Using the “Who wants what and why?” scenario (the user story) as a springboard, one can then move into the development of sub-stories, and before you know it, the system gets so complex that it requires a workflow diagram just to track everything. Wireframes and visual designs add supporting detail to the overall structure.

Nonfunctional requirements might include things like security protocols, backup systems, ensuring compatibility across platforms, and so on. These requirements are just as critical as their functional counterparts, so don’t ignore them! The next requirements stage after that involves the development of low-fidelity prototypes. All that “low fidelity” means is a simulation that can, with the least amount of effort, convey the desired result. It is something that “goes beyond…words and pictures,” putting abstract plans into context.

And the final, most fine-grained level requirements writing rests with test tables and test scripts. At this level of TDD or test-driven development, all possible inputs and outputs are explored using a table to guide developers and testers through a rigorous process of scrutiny. Some would characterize this process as a methodical, team-oriented attempt to intentionally break the software.

Read the original post at:

Eric Anderson

Eric Anderson is a staff writer for CAI's Accelerating IT Success. He is an intern at Computer Aid Inc., pursuing his master's degree in communications at Penn State University.

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button

We use cookies on our website

We use cookies to give you the best user experience. Please confirm, if you accept our tracking cookies. You can also decline the tracking, so you can continue to visit our website without any data sent to third party services.