61FIT3REQ – Software Requirements Analysis

Lecture 6
Requirements
Elicitation & Validation

Faculty of Information Technology

Hanoi University
REQUIREMENTS ELICITATION
Capturing Requirements
Software requirements faults & project failure
Relationship of requirements to other
software development tasks
Requirements-related contributions from various stakeholders
Requirement Engineering
 Requirements Elicitation
• Requirements elicitation is the process of
identifying the needs and constraints of the
various stakeholders for a software system.
• Previously referred to as “capturing requirements”
• Not just gathering requirements or recording exactly
what users say.
• The heart of requirements development
• A challenging, critical, error-prone, and communication-
intensive task
• Activities: collect, discover, extract, and define
requirements.
 Requirements Development Cycle

1. Do some elicitation
2. Analyze information you
obtained
3. Write some requirements
4. Discover missing information
5. Repeat from step 1
 Classifying users
• Good BA understand user classes
• User personality affects software requirements
• e.g. this man likes to work with visuals better than texts,
he has weak vision so he likes large text size, simple &
high contrast UI
• Categorize user into classes because:
• Pick a representative from each class for requirements
elicitation
• Different departments need different functionalities
from the software system
 Elicitation Technique: Workshops
• A structured meeting in which a carefully selected
group of stakeholders and content experts work
together to define, create, refine, and reach closure
on deliverables (such as models and documents)
that represent user requirements.
• Include several types of stakeholders, from users to
developers to testers.
• Combining people’s ideas
• Great for discussion
• Direct and immediate feedbacks
• Having too many participants is bad
• Don’t forget to record all discussion results.
 Elicitation Technique: Observations
• Watch users perform their tasks rather than
ask them to describe their tasks.
— User’s description can be incorrect or missing
information
• Observe user’s workflow to understand
business processes.
Elicitation Technique: Questionnaires
• Survey large groups of users to understand their
needs
• Identify priorities
• Result depends on quality of questionnaires
• Some tips for good questionnaires
• Have clear goals when designing questions
• Don’t phrase a question in a way that implies a “correct”
answer.
• Don’t ask too many questions or people won’t respond.
• If you use scales, use them consistently throughout the
questionnaire.
 Elicitation Techniques
• System interface analysis
• Examine the systems to which your system connects
• Reveals functional requirements regarding the
exchange of data between systems
• User interface analysis
• Study existing systems to discover user and
functional requirements
• Use screen shots if you are unable to access the
system directly
• Do not let the old system influence the new one
• Document analysis
 Classifying customer inputs
• Business requirements: any financial,
marketplace, or other business benefit that the
customer wishes to gain from the software
• Examples
• “Increase market share in region X by Y percent within Z
months”
• “Save $X per year on electricity now being wasted by
inefficient units”
 Classifying customer inputs
• User requirements: user goals or business tasks
that users need to perform
• Examples
• “I need to print a mailing label for a package”
• “As the lead machine operator, I need to calibrate the
pump controller first thing every morning”
 Classifying customer inputs
• Business rules
• Examples
• “A new client must pay 30 percent of the estimated
consulting fee and travel expenses in advance”
• “Time-off approvals must comply with the company’s
HR vacation policy”
• “Only VIP users can use the advanced search tools”
• Some functional requirements might be derived
to enforce the rules
 Classifying customer inputs
• Functional requirements: system behaviors,
actions that the system will let users take…
• Examples
• “If the pressure exceeds 40.0 psi, the high-pressure
warning light should come on”
• “The user must be able to sort the project list in forward
and reverse alphabetical order”
• The BA will need to craft these into more
logical, organized requirements specification
 Classifying customer inputs
• Quality attributes: statements that describe
how well the system does something.
• Quality requirements from users are usually
ambiguous and subjective
• Examples
• “The mobile software must respond quickly to touch
commands”
• “The shopping cart mechanism has to be simple to use
so my new customers don’t abandon the purchase”
 Classifying customer inputs
• Constraints: design and implementation
constraints that restrict the options available to
the developer.
• Examples
• “Files submitted electronically cannot exceed 10 MB in
size”
• “The device’s screen size is 4 inches”
• “The browser must use 256-bit encryption for all secure
transactions”
 Classifying customer inputs
• Data requirements: format, data type, allowed
values, or default value for a data element;
reports to be generated.
• Examples
• “The ZIP code has five digits, followed by an optional
hyphen and four digits that default to 0000”
• “An order consists of the customer’s identity, shipping
information, and one or more products, each of which
includes the product number, number of units, unit
price, and total price”
 Classifying customer inputs
• Solution ideas: customer may suggests specific
ways to interact with the system to perform
some action.
• BA should repeatedly ask “why” to reveal the
true needs of customer.
• Examples
• “Then I select the state where I want to send the
package from a drop-down list”
• “The phone has to allow the user to swipe with a finger
to navigate between screens”
 Signs of completion
• The users can’t think of any more use cases or
stories.
─ Users tend to identify user requirements in sequence of
decreasing importance.
• New scenarios don’t lead to new functional
requirements.
• Suggested new features, user requirements, or
functional requirements are out of scope.
• Developers and testers don’t have any more
question after requirements review.
 Cautions when capturing requirements

• Balance stakeholder representation

─ Don’t just capture requirements from the loudest user.
─ Get inputs from all user classes.
• Make scope adjustments
─ During elicitation, you might find the project scope too
large or too small.
• Requirements-versus-design
─ Requirements: “what”, design: “how”.
─ Analysis models, sketches and prototypes during
elicitation help clarify needs and are valuable inputs for
analysis & design.
 Assumed and implied requirements

• Assumed requirements: those that people

expect without explicitly expressing them.
─ User’s assumptions might be different from developer’s
assumptions.
─ Review the existing system’s features because users
expect similar things in the new system.
• Implied requirements: those which are
necessary because of other requirements but
aren’t explicitly stated.
─ Developers can’t implement functionality they don’t
know of.
 Finding missing requirements

• Decompose high-level requirements into

enough details.
• Ensure that all user classes have provided input.
• Link system requirements, user requirements,
event-response lists, and business rules to their
corresponding functional requirements.
• Represent requirements information in more
than one way.
• A data model (such as DFD) can reveal missing
functionality.
 Finding missing requirements

• Check boundary values for missing

requirements.
• Example:
• Re1: “If the price of the order is less than $100, the
shipping charge is $5.95”.
• Re2: “If the price of the order is more than $100,
the shipping charge is 6 percent of the total order
price”.
• What’s the shipping charge for an order with a
price of exactly $100?
REQUIREMENTS VALIDATION
Requirements Review & Inspection
Nine Quality Measures
• Correct

• Unambiguous
• A requirement is subject to only one
interpretation.

• Complete
• All significant requirements of concern to the
user, including requirements associated with
functionality, performance, design constraints,
attributes, or external interfaces.
 Ensuring Completeness
• Make use of prototyping.
• For functional requirements:
• Requirements must describe system behaviors for both
valid and invalid inputs.
• Consider possibilities of failures.
• For non-functional requirements:
• Not to overlook performance and design constraints or
assumptions about external interfaces to other systems.
• Use a checklist of quality factors.
Nine Quality Measures
• Consistent
• No subset of individual requirements described
within it are in conflict with one another.
• Ranked for importance and stability
• This ranking process is particularly important for
scope management.
• A set of requirements is verifiable:
• If each of the component requirements is
verifiable.
• If the developed software system can be tested
using a finite, cost-effective process.
Nine Quality Measures
• Modifiable
• Any changes to the requirements can be made easily,
completely, and consistently, while retaining the
existing structure and style of the set.
• Traceable
• The origin of component requirements is clear.
• It feasible to refer to requirements later on.
• Understandable
• Both users and developers can fully comprehend
individual requirements.
Requirements Reviews
• Peer-review: Someone other than the author of
a work product examines the product for
problems.
• Peer desk-check: ask one colleague to look over your
work product.
• Pass-around: invite several colleagues to
concurrently examine a deliverable.
• Walkthrough: the author describes a deliverable and
a committee comments on it.
• Formal inspection
• Fagan Inspection process.
Fagan’s guides on Inspection
• Fagan Inspection is a well-defined multistage
process
• Recognized as a software industry best practice
• Can also be applied to
• Design documents, source code, test documentation, and
project plans
Fagan Inspection - Participants
• The author of the work product
• The BA who wrote the requirements
• People who provide information
• Various people can be sources of requirements
• e.g. user, old software’s developer...
• People who will use the work product
• e.g. developer, tester, project manager,
user manual writer...
• Representatives from external systems
• Check problems with the external interface requirements
Fagan Inspection - Entry criteria
• A checklist before deciding to proceed with the
inspection
• Also called “pre-conditions”
• Some suggestions:
• The document conforms to template and doesn’t have
obvious spelling, grammatical, or formatting issues.
• Line numbers or other unique identifiers are printed on
the document to facilitate referring to specific locations.
• All open issues are marked as TBD (to be determined)
• Less than 3 major defects are found in a 10-min
examination of a randomly chosen sample document.
Fagan Inspection - Inspection stages

The dotted lines indicate that

portions of the inspection
process might be repeated to
inspect extensive work
Fagan Inspection - Exit criteria
• Used in the Follow-Up step to decide closure to
the inspection process
• Follow-Up’s goal is to ensure all open issues were resolved
and errors were properly corrected
• Some suggestions:
• All issues raised during inspection have been addressed.
• Changes in the requirements and related work products
were made correctly.
• All open issues have been resolved or properly planned.
Acceptance criteria
“How would you judge whether the
solution meets your needs?”
• Acceptance criteria: a set of conditions of
satisfaction being placed on the system.
• Acceptance criteria define the minimum conditions
for an application to be considered business-ready.
• Often written by customers.
• Acceptance criteria are used for testing
requirements.
Writing acceptance criteria
• Focus on stakeholders’ business objectives or the
conditions that would bring benefits to the
project sponsor
• Some suggestions:
• High-priority features that must be operating properly
• Essential non-functional qualities that must be satisfied
• Severe issues and defects that must be fixed
(minor bugs can be allowed)
• Legal issues and regulations that must be observed
• Training materials which must be available