Developing quality software -- software that does what users want and performs well -- starts with the requirements process. If you fail here, your project fails. You end up with software that isn't used -- not to mention wasted time, energy, and money. These software requirements tips -- the most popular and highly rated from 2007 and 2008 -- can help you prevent that.
1. Software requirements analysis: Five use case traps to avoid
Employing use cases during software requirements analysis helps you improve your chances of developing software that truly meets their needs. But there are traps you should avoid, says expert Karl E. Wiegers.
2. How to document system, software requirements
There are various formats you can use to document system and software requirements. However, no single one is sufficient to represent all requirements. You need to follow an integrated approach.
3. Software requirements: Using models to understand users' needs
Successful software projects involve users early and often to explore and reach closure on requirements. Using analysis models you can depict user needs with a combination of diagrams and structure text such as tables or templated text.
4. Approaches to defining requirements within Agile teams
Agile development methods focus on defining "just enough" requirements detail for the next sprint. Martin Crisp explains three things to consider when eliciting those requirements.
5. Tuning up your software requirements reviews
The most powerful quality practice available to the software industry today is inspection of software requirements documentation. The problem is most organizations don't do them or do them badly. Karl E. Wiegers offers advice for holding more effective requirements reviews.
6. How a business analyst can help on a software project
Business analysts not assigned a primary role in software requirements development are still valuable to the project. Using their analyst skills and experience, they can help users better communicate their needs, identify and document business rules and participate in reviews of the requirements specifications.
7. Don't overlook nonfunctional software requirements
Nonfunctional software requirements describe how well the software does what it does. By exploring quality attributes during requirements elicitation, you can influence the function, design and architecture of the product and help give customers something they really like.
8. Quality software performance doesn't happen accidentally
Quality application performance cannot be achieved unless you specify it. Using software performance requirements, you can address important user concerns for efficiency, interoperability, robustness and testability.
9. Defining good performance requirements a joint effort
When dealing with performance requirements you need to look at a bigger picture -- one that includes business, operations and development organizations -- as well as consider changes to the system over time. Doing so helps you produce systems that align with the business need.
10. Ambiguous software requirements lead to confusion, extra work
Ambiguous requirements lead to confusion, wasted effort and rework. This article from software requirements expert Karl E. Wiegers, Ph.D. describes several common types of requirements ambiguity and suggests how to avoid them.
