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.
Requires Free Membership to View
When you register, you'll receive targeted emails designed to keep you informed of the most relevant information on Agile development, application security, testing & QA, software requirements, and more.
Hannah Smalltree, Editorial Director
Software
requirements analysis: Five use case traps to avoidEmploying 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.
This was first published in October 2008
Join the conversationComment
Share
Comments
Results
Contribute to the conversation