In this Slide
____________________________________________________________
SRE – Requirements Analysis, Prioritization and Specification
BSEF15
(V)
Abdul
Razaq Ali
Requirements Analysis & Prioritization
Reasons
(Why)
Occurrences
(When)
Techniques
(How)
Trigger !
Requirements
Engineer: “what requirements are the most important to you…”
Customer:
”All are… I need everything, otherwise they wouldn’t be specified…!”
Why Prioritize ?
We
don’t have enough money!
We
don’t have enough time!
We
don’t have enough people!
Avoid
risk or penalty!
We
have to improve maintainability!
We
have to improve the performance!
We
have to meet the new customer demands!
We
have to fix improve software already in use!
When Prioritize ?
Pre-project
(sometimes at initial stages of project)
Stakeholder prioritization
Operator prioritization
During
project
Re-prioritization (Change management)
Continuous
Important
Ask stakeholders and keep them informed
throughout the project
Establish an understanding of why
things change
Establish an understanding of what impact new requirements / changed requirements and the
project as a whole
Prioritization Techniques
Define
scale for requirements –prioritization can be done informally in small projects
where you rate requirements on different scales
Prioritization Techniques
Cost-Value
Some requirements are High-value and low-cost, others are
Low-value and high-cost
Pareto-principle(vital few, trivial many)
20% of the requirements for 80% of value
20% of the requirements for 80% of cost
20% of the requirements for 80% of risk
Binary
Tree
Requirements are divided and subdivided till they are
atomic
Logical path are defined which makes
it easy to prioritize while knowing their dependencies
100
–Point method
Assign values to requirements till 100 points threshold are
reached, the more points, the more important
Cost-Value
Prioritization Techniques
MoSCoW
M -MUST: Describes a requirement that
must be satisfied in the final solution
S -SHOULD: Represents a high-priority
item that should be included in the solution if it is possible.
C -COULD: Describes a requirement
which is considered desirable but not necessary.
W -WON'T: Represents a requirement
that stakeholders have agreed will not be implemented in a given release, but
may be considered for the future.
Benefits of Prioritization
Establish
what really matters / is important to the stakeholders (which includes
customers)
Establish
development factors
What to implement
Implementation order
What requirements. can be downsized
from projects if necessary (in case of problems, new requirements etc)
Gives
project management Options to handle change and real world occurrences –balance
Better to establish priority at an
early stage than when the crisis occurs, i.e. planned vs. panic initiated.
Establish
trust
As the customer realizes why
prioritization is done, he/she will see that making money isn’t your primary
goal. (CUSTOMER SATISFACTION IS!)
Requirements Specification
Requirement
elicitation and specification runs in parallel for initial phase until complete
set of requirements is not identified.
We
already have studied all the methods for Requirements Elicitation like
Interviewing, scenarios, prototyping etc.
SRS
–IEEE document overview
Section 4 –Important considerations in
writing a Good SRS
Section 5 –Parts of SRS
Reference
Book1, chap 10
Questions ?
No comments :
Post a Comment