Requirements Development
●Requirements
development are subdivided into elicitation, analysis, specification, and
validation.
They are done iteratively and including
the following:
§Identifying the product's expected user
classes
§Eliciting needs from individuals who
represent each user class
§Understanding user tasks and goals and
the business objectives with which those tasks align
§Analyzing the information received from
users to distinguish their task goals from functional requirements,
nonfunctional requirements, business rules, suggested solutions, and extraneous
information
§Allocating portions of the top-level
requirements to software components defined in the system architecture
§Understanding the relative importance of
quality attributes
§Negotiating implementation priorities
§Translating the collected user needs into
written requirements specifications and models
§Reviewing the documented requirements to
ensure a common understanding of the users' stated requirements and to correct
any problems before the development group accepts them.
Requirements Management
●Requirements management entails
"establishing and maintaining an agreement with the customer on the
requirements for the software project" . Requirements amanagement
activities include the following:
§Defining the requirements baseline (a
snapshot in time representing the currently agreed-upon body of requirements
for a specific release)
§Reviewing proposed requirements changes
and evaluating the likely impact of each change before approving it
§Incorporating approved requirements
changes into the project in a controlled way
§Keeping project plans current with the
requirements
§Negotiating new commitments based on the
estimated impact of requirements changes
§Tracing individual requirements to their
corresponding designs, source code, and test cases
§Tracking requirements status and change
activity throughout the project
The boundary between requirements development and requirements management
●The hardest single part of building
a software system is deciding precisely what to build. No other part of the
conceptual work is as difficult as establishing the detailed technical
requirements, including all the interfaces to people, to machines, and to other
software systems. No other part of the work so cripples the resulting system if
done wrong. No other part is more difficult to rectify later.
Relative cost to correct a requirement defect depending on when it is discovered
Common requirements risks
●Insufficient User Involvement
§Customers often don't understand why it
is so essential to work hard on gathering requirements and assuring their
quality. Insufficient user involvement leads to late-breaking requirements that
delay project completion. There's no substitute for having the development team
work directly with actual users throughout the project
●Creeping User Requirements
§As requirements evolve and grow during
development, projects often exceed their planned schedules and budgets. To
manage scope creep, begin with a clear statement of the project's business
objectives, strategic vision, scope, limitations, success criteria, and
expected product usage. Evaluate all proposed new features or requirements
changes against this reference framework
●Ambiguous Requirements
§One symptom of ambiguity is that a reader
can interpret a requirement statement in several ways. Another sign is that
multiple readers of a requirement arrive at different understandings of what it
means. One way to ferret out ambiguity is to have people who represent
different perspectives formally inspect the requirements. Writing test cases
against the requirements and building prototypes are other ways to discover
ambiguities.
●Gold Plating
§Gold plating
takes place when a developer adds functionality that wasn't in the requirements
specification but that the developer believes "the users are just going to
love." To reduce the threat of gold
plating, trace each bit of functionality back to its origin so that you know
why it's included. The use-case approach for eliciting requirements helps to
focus requirements elicitation on the functionality that lets users perform
their business tasks.
●Minimal
Specification
§Sometimes marketing staff or managers are
tempted to create a limited specification, perhaps just a product concept
sketched on a napkin. They expect the developers to flesh out the spec while
the project progresses.
●Overlooked
User Classes
§Most products have several groups of
users who might use different subsets of features, have different frequencies
of use, or have varying experience levels. If you don't identify the important
user classes for your product early on, some user needs won't be met.
●Inaccurate
Planning
§Vague, poorly understood requirements
lead to overly optimistic estimates, which come back to haunt us when the
inevitable overruns occur.
Benefits from a High-Quality
Requirements Process
●Fewer
requirements defects
●Reduced
development rework
●Fewer
unnecessary features
●Lower
enhancement costs
●Faster
development
●Fewer
miscommunications
●Reduced
scope creep
●Reduced
project chaos
●More
accurate system-testing estimates
●Higher
customer and team member satisfaction
Requirement Statement Characteristics
Complete,Correct,Feasible,Necessary,Prioritized,Unambiguou,Verifiable
end of chapter
No comments:
Post a Comment