Software Requirements Elicitation Requirements specify a set of functions a software development project must deliver. Functional requirements define system capabilities, for example, “The system shall permit users to inquire about Berta’s Pizzeria menu via an email message.” Additionally requirements specify non-functional standards that the system must operate within. Examples of non-functional requirements are performance, quality, safety, security, and interface requirements. An example of a performance requirement is, “The system shall have the ability to process 1MB/sec of input.” An example of a quality requirement is, “The MTBF (mean time between failures) shall be greater than 90 days.” The iterative and incremental development processes of agile methods permit frequent changes to requirements and documentation. Early requirements analysis is required only for features developed in early iterations. Scrum and XP are agile methods that facilitate requirements gathering flexibility. Agile methods require direct involvement of the end-user though-out the software lifecycle. The requirement elicitation differs depending on the agile methodology used. The Unified Process (UP) creates use cases as requirements. Scrum records initial requirements in the form of a product backlog and prioritises them. Extreme Programming (XP) derives user stories and organizes them on a corkboard, or storyboard into deliverables for each iteration. Requirements elicitation is considered the most difficult part of a development project. The Importance of identifying correct requirements is valuable to the both software developer and the customer. Systems delivered according to incorrect or inadequate requirements may be disparaging to the development organization and disappointing and wasteful to the client. Difficulties with requirements elicitation and analysis include: 1. lack of domain knowledge by the development team 2. Users are not knowledgeable of software capabilities 3. A communication disconnect between the users and the development team 4. Stakeholders cannot definitively specify the requirements 5. Stakeholders underestimate the importance of requirements gathering 6. Nonfunctional requirements are not addressed 7. Stakeholders alter the requirements during the software lifecycle Requirements elicitation steps include: 1. collection of application information 2. optionally building analysis models 3. developing requirements and constraints 4. feasibility study 5. requirements specification review The collection of application information involves inquiries about internal and external influences on the business environment, policies, regulations, business goals, and standards. Analysis models may be constructed to understand the business processes and objectives. The customer or user plays a critical role in driving and prioritizing requirements to satisfy the business needs. When the practicability of implementing particular requirements is in q.

1. Software Requirements Elicitation
Requirements specify a set of functions a software development
project must deliver. Functional requirements define system
capabilities, for example, “The system shall permit users to
inquire about Berta’s Pizzeria menu via an email message.”
Additionally requirements specify non-functional standards that
the system must operate within. Examples of non-functional
requirements are performance, quality, safety, security, and
interface requirements. An example of a performance
requirement is, “The system shall have the ability to process
1MB/sec of input.” An example of a quality requirement is,
“The MTBF (mean time between failures) shall be greater than
90 days.”
The iterative and incremental development processes of agile
methods permit frequent changes to requirements and
documentation. Early requirements analysis is required only for
features developed in early iterations. Scrum and XP are agile
methods that facilitate requirements gathering flexibility. Agile
methods require direct involvement of the end-user though-out
the software lifecycle. The requirement elicitation differs
depending on the agile methodology used. The Unified Process
(UP) creates use cases as requirements. Scrum records initial
requirements in the form of a product backlog and prioritises
them. Extreme Programming (XP) derives user stories and
organizes them on a corkboard, or storyboard into deliverables
for each iteration.
Requirements elicitation is considered the most difficult part of
a development project. The Importance of identifying correct
requirements is valuable to the both software developer and the
customer. Systems delivered according to incorrect or
inadequate requirements may be disparaging to the development
organization and disappointing and wasteful to the
client. Difficulties with requirements elicitation and
analysis include:

2. 1. lack of domain knowledge by the development team
2. Users are not knowledgeable of software capabilities
3. A communication disconnect between the users and the
development team
4. Stakeholders cannot definitively specify the requirements
5. Stakeholders underestimate the importance of requirements
gathering
6. Nonfunctional requirements are not addressed
7. Stakeholders alter the requirements during the software
lifecycle
Requirements elicitation steps include:
1. collection of application information
2. optionally building analysis models
3. developing requirements and constraints
4. feasibility study
5. requirements specification review
The collection of application information involves inquiries
about internal and external influences on the business
environment, policies, regulations, business goals, and
standards. Analysis models may be constructed to understand
the business processes and objectives. The customer or user
plays a critical role in driving and prioritizing requirements to
satisfy the business needs. When the practicability of
implementing particular requirements is in question, a
feasibility study may take place to assess the risks associated
with implementing the requirements. Afterward, a requirements
review by all stakeholders, customers, users, domain experts,
and developers occurs. For the Unified process (UP), use cases
are then derived.
Agile development avoids passing extended lengths of time
gathering requirements. Requirements gathering for agile
develop deconstructs large projects into the highest priority
requirements and addresses an adequate amount of high priority
requirements in separate iterations. Stakeholders develop a list
of high priority requirements that are expected to change during
succeeding iterations. Agile requirements elicitation adheres to

3. the following principles
1. Customer participation and active end-user involvement are
essential
2. Stakeholders gather requirements at a high-level and defer
details to future iterations
3. Stakeholders quickly produce a software requirements list
and go to the next step
4. If needed, stakeholders quickly build models for analysis
during requirements elicitation
Deriving Use Cases From Requirements
When developing software using the Unified Process (UP)
stakeholders derive use cases from requirements. A use case
provides interaction details about an actor interacting with a
software application to accomplish a business task.
Use cases have four essential attributes.
1. A use case describes a functional process
2. An actor initiates a use case
3. An actor ends a use case
4. A use case must model an operational undertaking of the
actor
There are five steps to derive use cases from requirements.
1. Identify use cases
a. Identify use cases by reviewing the requirements and
searching for verb-noun phrases, such as register customer,
respond email, or order pizza. These verb-noun phrases suggest
business processes.
b. Additionally, actors may be derived from noun phrases. For
example, from the verb-noun phrase, register customer, the
actor, customer, could be derived.
c. Stakeholders can derive subsystems from the verb-noun
phrases. Stakeholders might derive a website subsystem from
the verb-noun phrase, authenticate website visitor. Organize use
cases by the subsystem.
d. Create a traceability matrix. A traceability matrix shows how
stakeholder map each use case back to a requirement.
2. Specify use case scope

4. The scope of a use case, where it begins and where it ends, is
specified in a high-level use case. A stakeholder must specify
three (3) pieces of information for each use case.
1. The action by the actor that starts the use case
2. Where the action by the actor occurs
3. The action the actor performs to signify an end to the use
case.
Use cases should contain two declarative sentences that start
and end the use cases.
1. The first sentence is patterned as follows, “This use case
begins when (TUCBW),” the actor performs an action and
where the actor performs the action.
2. The second sentence is patterned as follows, “This uses case
ends when (TUCEW),” the actor acknowledges that the business
objective of the use case was fulfilled. The actor’s
acknowledgment could be implicit or explicit.
Example:
Specify high-level use cases for login into a website
UC1. Login a website
1. TUCBW a visitor browses to the Berta’s Pizzeria website
login page.
2. TUCEW the visitor sees the website’s main page
3. Visualize use case contexts
Textual use cases are not appropriate for large systems, UML
use case diagrams are suitable to depict use cases for systems
with many actors and subsystems.
A use case diagram is described below.
1. A behavioral UML diagram
2. Shows actors that interact with the system
3. Shows the boundaries of the system or subsystem
4. Shows inheritance between actors
5. Shows relationships between use cases
Table 1 Use case notation
Figure 7 Use case diagram that shows actor inheritance

5. 4. Review the use cases and diagrams
The abstract or high level use cases and use case diagrams are
reviewed.
5. Assign use cases to iterations
The use cases are prioritized according to the requirements’
priorities. Now iterations are planed using use cases. Three (3)
factors should be taken into account when planning the
schedule.
1. Use case priorities
2. Dependencies between use cases
3. The effort required to implement the use cases
Running Heading: USE CASES 1
USE CASES 2
Use Cases
Roger Schlueter
Grantham University
2-16-17
High Level Use Cases
a. Customer registration
Name: CustomerRegistration
Actors: (Customer), admin, verification system
Type: Primary
Description:
R1. Customer enters registration information
R2. Customer information is authenticated and coockie

6. stored
R3. Customer verifies through email to complete
registration
b. Customer order
Name: CustomerOrder
Actors: (Customer), store, orders inventory
Type: Primary
Description:
R4. Customer selects a maximum of 3 pizzas
R5. Customer selects add side items and/or beverages
R6. Customer chooses the delivery
c. Customer checkout
Name: CustomerCheckout
Actors: (Customer), payment system, order fulfillment system,
Berta’s system
Type: Primary
Description:
R7. Customer reviews order and confirm
R8. Customer makes payment
R9. Payment System encrypts customer’s payment
information
R10. System transfers orders to the order fulfillment
system
R11. Berta’s system achieves the order details
d. Customer credit card processing
Name: CustomerCardProcessing
Actors: (Customer), Merchant's Credit Card Processing System,
Merchant's Bank
Customer's Credit Card Bank
Type: Primary
Description:
R12. System sends payment information to Customer's
Credit Card Bank
R13 Customer's Credit Card Bank processes payment and
order confirmation number returned.