Software Requirements Specification Iteration and Prototyping

Developing great software requirements demands iteration

In our previous post of an example of the software development process, we showed a linear flow through the process, as depicted in several posts over a couple weeks. What we failed to show was any of the iteration cycles, as Deepak points out by asking a great question in the comments on that post. In this post, we will show a little more about how the process works by showing how iteration fits into the machinery of software development.

We showed a simplified view of the requirements process (and roles) in an earlier post. Here’s a review of the steps described in that post.

1. Identify market opportunities
2. Express software requirements
3. Design solution (high level)
4. Design (low level) and implement solution

We iterated within the process for this project. We followed the following steps on this project:

1. Define the market requirements (MRD)
2. Define software requirements (PRD)
3. Design a solution
4. Validate requirements and design with the users, uncovering new requirements and improving our analysis of benefits
5. Repeat steps 2-4 until satisfied (in our case – once was enough)
6. Implement

This provides us with an incrementally more refined view of the overall software development process.

Iteration is most effective when combined with prototyping

In our iterative process, we validated the use cases, the cost-benefit-analysis, and got usability feedback*.

We were introducing a new concept to our potential users, and inital conversations were awkward. By applying active listening techniques, we realized that we weren’t getting our message across. We created prototypes (screen mockups) and used them to demonstrate the proposed design, and we got the ah-ha moments were looking for.

Once we got the mindshare, we were able to elicit inputs on the cost-benefits, usability improvements to the design, and other potential requirements. We cycled back into an update of our PRD and our design and validated again.

By iterating the requirements and design we were able to

• completely eliminate two screens in the user interface
• improve the usability of the tool
• reduce the cost to implement!

We were able to make these changes because during the validation steps we identified low-value use cases that we could eliminate entirely by adding simple steps to other use cases.

We then moved on to another step in the process – putting together a detailed estimate, work breakdown structure, and ROI analysis.

Thanks again to Deepak for asking the question and pointing out that we’ve failed to share this critical step.

*Usability is not technically what we analysed – we got feedback on how two potential users believed they would use the tool. We did not perform a discount usability study, or anything more formal. The UX/HCI folks will appreciate the distinction between how users use a prototype and how they believe they will use a prototype. Everyone else will just roll their eyes.