Requirements Collection

By Dr. Gabriel
 Requirements
• A requirement is any function, constraint, or property that
the system must provide, meet, or satisfy in order to fulfill
its purpose.
• Requirements may be separated into two broad
categories, functional and non-functional
– A functional requirement is a function that the system must perform.
• Summarize Sales
• Create Paychecks
• Receive Shipment
– A non-functional requirement is a characteristic or constraint that might limit our
choice of technology when we implement one or more functional requirements.
• Availability
– Users must be able to access the system twenty fours hours per day.
• Capacity/Performance
– The system must be able to handle a peak load of thirty simultaneous
users with no more than five second response time.
• Time
– The system must be implemented by December 31, XXXX.
 Requirements
• Requirements may be placed in two other
categories that are useful to designers and builders.
– Priority
• Mandatory
– The system will not be useful unless the requirement is met.
• Desirable
– The system will be more useful if the requirement is met. The
requirement must be considered when alternative solutions are
evaluated.
• Optional
– The system might be more useful if the requirement is met but
the requirement should not be considered when alternative
solutions are evaluated.
– Stability
• Stable
– The requirement is not likely to change over the useful life of
the system.
• Volatile
– It is very likely that the requirement will change over the useful
life of the system.
 Requirements
• Requirements must be:
– Correct
• A requirement is correct if it describes something that a system must do or a
constraint on the way it must be done.
– Complete
• A requirement is complete to the extent that all parts are present and each
part is fully developed. The requirement set is complete if it contains all of
the complete requirements.
– Consistent
• A requirement is consistent if it does not conflict with another requirement.
– Nonambiguous
• A requirement is non-ambiguous if there is only one interpretation of its
meaning
– Verifiable
• A requirement is verifiable if and only if there is a finite cost effective process
that a person or machine can use to check that the as built system meets
the requirement. (Ambiguous and qualitative (subjective) requirements are
not verifiable)
– Traceable
• An analysis requirement is traceable if it can be traced backward to a
feasibility study, a white paper, meeting notes, or an interview.
 Requirements Elicitation
Techniques
• Collaborative sessions
• Interviewing
• Ethnography
• Questionnaires
• Role playing
• Documentation
• Modeling
• Prototyping
 Requirements Elicitation
Techniques
• Collaborative sessions
– Primarily useful for brainstorming and problem
solving activities
– It is a useful technique
– Useful for identifying and negotiating conflicts
that might exist between requirements.
 Requirements Elicitation
Techniques
• Interviewing techniques
– Are one of the simplest methods of requirements
elicitation.
– Most effective methods of requirements elicitation.
– Interviews can either be structured around a specific
set of questions, or open-ended with the intention of
gathering as much useful information as possible.
– It is often beneficial to combine both techniques in a
single interview.
– Interviews are often conducted in stages, so that
responses from the first round can be used to
generate a deeper set of more focused questions for
the second round.
 Requirements Elicitation
Techniques
• Ethnography
– Involves observing the way users interact with
an existing system.
– This is particularly useful when users are
unable to fully articulate their needs, or are
too busy to attend other types of elicitation
meetings.
 Requirements Elicitation
Techniques
• Questionnaires
– Can be useful if it is possible to formulate a very
specific set of questions.
– This usually is only possible when the problem is
quite well defined up front.
– Tend to be used more frequently in the form of market
research surveys when developing a product for an
external client, or to elicit a general response from a
targeted group of stakeholders such as the users of
an existing system.
 Requirements Elicitation
Techniques
• Role-playing
– Can be used to explore stakeholders needs
when those stakeholders are unavailable.
– This is particularly useful for example if you
are developing a product that will be mass
marketed and you don’t know who the actual
users will be.
 Requirements Elicitation
Techniques
• Documentation
– Can provide significant insights into possible
requirements.
• Problem reports
• Memos
• User manuals from existing systems
• Existing designs and specifications
• Reports output from existing systems
• Documentation from competitors’ products
 Requirements Elicitation
Techniques
• Modeling
– Can be used during the elicitation process primarily
as a means of communicating back to the user the
specific understanding of their needs.
• Data flow diagrams (DFD),
• State charts
• Use cases and sequence diagrams
– A model is useful during elicitation if it helps the
elicitor to figure out which questions to ask, or if it
surfaces hidden requirements.
– In general, formal models are not that useful during
the elicitation process primarily because they are
typically not well understood by stakeholders.
 Requirements Elicitation
Techniques
• Prototyping
– is a useful technique for taking an early set of
user requirements and rapidly building a
‘system’ that can be used to elicit additional
requirements.
– There are various types of prototypes.
• Low fidelity models are built with pen and paper,
index cards, and post it notes etc.
– very little cost.
• Higher fidelity prototypes, that utilize rapid
development techniques to deliver a semi-
functioning product to the user
 Requirements
• Requirements document states what the system will do.
– It does not state how the system will do it.
– Makes sure system does the right things
– Makes sure system doesn’t do the wrong things
• It’s a written document
• The main purpose of a requirements document is to
serve as an agreement between the developers and the
users/customers on what the system will do.
• The requirements document brings the following
additional benefits:
– the customers can see early on if their needs will be met
– the developers can estimate the effort involved in creating the
application
– the development project leader has a basis for a project plan
– the quality assurance people have a basis for testing the application
 Requirements
• Take iterative approach when writing
requirements document
• When you are collecting requirements it is very
important to verify all of the facts by interviewing
customers with differing points of view
• users and management
• users in different parts of the organization; etc.
• Remember that different people in the same
position and especially people in different positions
have a different view of the business needs and
business practices as far as your application is
concerned.
 Requirements
– A requirements document should include requirements that meet
all characteristics of requirements. In addition, a requirements
document should be:
• Understandable
– A requirements document is understandable if it can be
read and understood by those who were the source of
the requirements and those who will use the
requirements to create the system.
• Modifiable
– A requirements document is modifiable if its structure
and style are such that changes to the requirements can
be made easily, completely, and consistently.
• Annotated
– A requirements document is annotated if the relative
priority and stability is appended to each requirement.
 Requirements
• Each requirements document
consists of at least two parts
– An overview
– A description of the system’s functionality.
• You must continue updating the
document as the requirements
evolve.
Questions ?