10 requirements traps to avoid Flashcards
(32 cards)
What are the first 5 requirement traps to avoid?
- Confusion over Requirements
- Inadequate Customer involvement
- Vague and Ambigous requirements
- Unprioritized requirements
- Building functionality no one uses
What are the last 5 requirement traps to avoid?
- Analysis paralysis
- Scope Creep
- Inadequate Change Process
- Insuffiecient Change impact analysis
- Inadequate version control
What are business requirements?
High-level objectives of the organization or customer requesting the system or product
What are user requirements?
They describe the tasks that the users must be able to perform using the new product
What are functional requirements?
Requirements that itemize the specific behaviors the software must exhibit
What are some examples of quality attributes?
Usability, efficiency, portability and maintainablitiy
What is the purpose of the software requirements specification (SRS)?
It serves as a container for both the functional requirements and the nonfuctional requirements.
How does confusion over requirements arise?
The term requirements can mean different things to different people.
What is the problems with inadequate customer involvement?
- Many projects rely on telepathy as the mechanism for communicating requirements from users to developers
- Users sometimes believe that the developers should already know what users need.
- Users claim to be too busy to spend the time it takes to gather and refine the requirements
How can you solve the problem of inadequate customer involvment?
Begin by identifying user classes and make use of product champions to represent specific user classes and provide input on quality attributes and requirement priorities.
How can ambiguous and unclear requirements arise?
Ambiguity can arise from unclear language, multible interpritations or implicit assumtions.
How can you avoid ambiguous requirements?
Use multiple representations, such as diagrams and prototypes to clarify requirements and review requirements carefully to identify and resolve any ambiguity.
Why shouldn’t you declare all requirements equally important?
Declaring all requirements equally important deprives the project manage
Why shouldn’t more than 90% of requirements be classified as high priority?
It can lead to mismatched expectations.
How can you solve the problem of unprioritized requirements?
By aligning business requirements, allocating requirements to specific builds/releases, and analytically prioritizing requirements based on customer value and estimated cost/technical risk.
What is the problem behind building functionality no one uses?
Some proposed funtionality isn’t clearly related to known user tasks or achieving business goals.
How to you solve the problem of building functionality no one uses?
By tracing functional requirements back to their origin, deriving functional requirements from use cases and having customers rate the value of each proposed feature.
How does analysis paralysis arive?
It is the result when the viewpoint prevails that construction cannot begin until the SRS is complete and perfect.
How do you solve the problem of analysis paralysis?
The solution includes developing a set of clearly expressed requirements that permit development to proceed at acceptable risk, selecting an appropriate development lifecycle, and identifying key decision-makers early in the project.
How does scope creep arise?
It arises when the product scope was never clearly defined in the first place.
What is the problem with scope creep?
If the scope definition is inadequate, new requirements can by proposed, rejected or resurface later, with ongoing debates about whether they belong in the system.
What is the solution to scope creep?
While all projects should expect some requirements growth, your plans should include buffers to accommodate such evolution. When a new feature, use case or functional requirement is proposed you should make sure that it is in scope.
What helps to answer if something is in scope?
To document the product’s vision and scope and use it as the reference for deciding which proposed functionality to include.
What does scope creep often indicate?
That requirements were missed during elicitation or that some user classes were overlooked.