Software Requirements

Engineering
Software Requirements Elicitation and Specification

1
 Software Requirements Elicitation and
Specifications
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

2
 Use Case

• A use case captures a contract between the stakeholders of a

system about the system behavior.
– What the actor expects from, sends to the system
– What the system ensures to, expects form the actor
• A use case describes the system’s behavior under various
conditions as the system responds to a request from one of the
stakeholders, called the primary actor.
– The primary actor has a goal with the software system
– And the system has a responsibility to satisfy that goal
• The system responds, protecting the interests of all the
stakeholders (not all stakeholders are actors)
• Different behaviors (i.e., scenarios) can unfold
– Including descriptions of what may go wrong

3
 Use Cases and Actors
• A primary actor has a goal with the software system
• The system has a responsibility: to achieve the goal of the
primary actor
• The system formulates sub-goals to carry out its responsibility
– Some sub-goals can become other use cases (carried out internally)
– Some sub-goals can be achieved with the help of another
(secondary) actor (carried our externally)
• Recall the fundamental question: Should we implement the requirements
or is the requested functionality a responsibility of another system or a
human?

4
 Use Case Scope/Extent

• How much does a use case describe?

– How many things are done in a use case
– How many scenarios?
– How many steps?
• Answer: what is the actor’s goal?
• A use case usually passes the one person, one sitting test
– Can the primary actor go away satisfied after the use case finishes?

5
 Use Case Scope/Extent (cont.)

• Some (potential) use cases do not pass this test, and should not
count as user goals:
– Use Case "Complete an on-line auction purchase“
• On-line auctions take several days, so fail the single-sitting test.
• This long “goal” should be split: e.g., making the auction publicly
available, making a bid, changing a bid, selecting the “winner”
• Instead
– Use Case "Register a new customer"
• Registering 42 new customers has some significance to a sales
agent.
– Use Case "Buy a book"
• A book purchase can be completed in a single sitting.

6
 Specifying a Use Case (template)

Use case are described by following template descriptions, which

typically include the following sections (many different templates exist):
• Use Case Name
• Brief Description
• Precondition
• Primary Actor
• Secondary Actors
• Success post condition
• Failure post condition
• Dependencies to other use cases
• Basic Flow
• Alternative Flows: Specific, Bounded, Global Alternative Flows
• Frequency
• Requirement

7
 Specifying a Use Case (cont.)
Use case name:
• Should be a verb phrase denoting what the actor is trying to accomplish
(goal)
• Should reflect the perspective of the actor
– E.g., “perform withdrawal” instead of “record withdrawal”
Precondition
• States what must always be true before any scenario of the use case
begins.
Primary Actor
– The principal actor that initiates the use case.
Secondary Actors
– The secondary actors that the system relies on to accomplish some of the
sub-goals.
Success Post Condition
– The states upon successful completion of the use case
Failure Post Condition
– The states upon Failed completion of the use case
Dependencies to other use cases (see later)
– <<include>> and <<exclude>> relationships between use cases. 8
– Generalization relationship between use cases.
 Specifying a Use Case (cont.)
Basic Flow
– Describes a typical success path that satisfies the interests of the
stakeholders. It often does not include any conditions or branching.
– A step can be one of the following interactions:
1. Primary actor à system: the primary actor sends a request and data
to the system.
2. System à system: the system validates a request and data.
3. System à system: the system alters its internal state (e.g., recording
or modifying something)
4. System à secondary actor: the system sends requests to a
secondary actor.
– The first step (outside this classification) often indicates the trigger event
that starts the scenario.
– All steps are numbered sequentially:
1. <description of first step>
2. <second step> …
– Use active voice only
– Postcondition: what should be true after the basic flow has executed.
9
 Specifying a Use Case (cont.)

Alternative flows
– Describe all the other scenarios or branches, both success and failure.
An alternative flow always depends on a condition occurring in a
specific step in a flow of reference, referred to as reference flow step
(RFS), and that reference flow is either the basic flow or an
alternative flow itself.
– All action steps are numbered sequentially.
– Each alternative flow must have a postcondition.
Three types of alternative flows:
– Specific alternative flow: an alternative flow that refers to a specific
step in the reference flow (either a main flow or another alternative flow).
– Bounded alternative flow: an alternative flow that refers to more
than one step (or range of steps) in the reference flow.
– Global alternative flow: an alternative flow that refers to any step in
the reference flow.

10
 Specifying a Use Case (cont.)

Requirements
– If a non-functional requirement, quality attribute, or constraint relates
specifically to the use case, list it here.

11
Specifying a Use Case (cont.)—possible layout

12
 Specifying a Use Case (cont.)

• See example of the report emergency use case (pdf file).

• See example of the withdraw funds use case (pdf file).

13
 Specifying a Use Case (restricting the use of
Language)
• The subject of a sentence should be “the system” or an actor.
– The card has been ejected. (passive voice)
– The system ejects the ATM card. (active voice)
• Describe the flow of events sequentially (a use case describes
what should happen).
• Actor-to-actor interactions are not allowed (these interactions
are not supported by the software you specify, are they?).
– The customer gives the teller the ATM card.
– The customer inserts the ATM card into the card reader.
• Describe one action per sentence.
• Use present tense only.
– The system ejected the card.
– The system ejects the card.
• Use active voice rather than passive voice.
– The card is ejected.
14
– The system ejects the card.
 Specifying a Use Case (cont.)
• Clearly describe the interaction between the system and actors
without omitting its sender and receiver.
– Customer enters PIN.
– ATM customer enters PIN number to the system.
• Use declarative sentence only. “Is the system idle?” is a non-
declarative sentence.
– Ejects the card.
– The system ejects the card.
• Use words in a consistent way. Keep one term to describe one
thing.
– Customer inserts the ATM card…
– ATM customer inserts the ATM card…
• Don’t use modal verbs (e.g., might) nor adverbs (e.g., very)
– The system might eject the card. The system likely ejects the
card.
– The system ejects the card. The system ejects the card 15
 Specifying a Use Case (cont.)
• Use simple sentences only. A simple sentence must contain only
one subject and one predicate.
System displays customer accounts and prompts customer for
transaction type…
1. The system displays ATM customer accounts.
2. The system prompts ATM customer for …
• Don’t use negative adverb and adjective (e.g., hardly, never), but
it is allowed to use not or no.
– The PIN number has never been validated.
– The PIN number has not been validated
• Don’t use pronouns (e.g. he, this, it)
– …it reads the card number.
– …the system reads the card number.
• Don’t use participle phrases as adverbial modifier.
– ATM is idle, displaying a Welcome message.
– The system is idle. The system is displaying a Welcome message.
16
 Specifying a Use Case (cont.)

• INCLUDE USE CASE = including another use cases.

– Grammar
• INCLUDE USE CASE <included use case name>
– Example:
• Include ValidatePIN use case.
• INCLUDE USE CASE ValidatePIN
• EXTENDED BY USE CASE = extension by another use case.
– Grammar
• EXTENDED BY USE CASE <extending use case>
– Example:
• Use case CreateIncident extends the current use case.
• EXTENDED BY USE CASE CreateIncident

17
 Specifying a Use Case (cont.)

• RFS = reference flow step (number(s))

– Grammar
• RFS <reference flow step #> (specific alternative flow)
• RFS <reference flow step numbers> (bounded alternative flow)
• Not required for global alternative flow.
– Explanation
• One specific or bounded alternative flow must correspond to exactly one or
more than one reference flow steps.
– Example:
• RFS Basic Flow 5 …
• RFS Basic Flow 5-7, 10, 14 …
• IF, THEN, ELSE, ELSEIF, and ENDIF = conditional logic.
– Grammar
• IF <condition> THEN <steps> ENDIF
• IF <condition> THEN <steps> ELSE <steps> ENDIF
• IF <condition> THEN <steps> ELSEIF <condition> THEN <steps> ENDIF
– Example:
IF the system recognizes the ATM card, THEN the system reads the ATM
card number, ENDIF.
it is advisable to avoid using "IF THEN" conditions within the steps. Such
conditions can complicate the understanding of the use case, instead make18
use of alternate flows when you can
 Specifying a Use Case (cont.)

• MEANWHILE = concurrency.
– Grammar
• <action> MEANWHILE <action>
– Example:
• the system cancels the transaction and ejects the card.
• the system cancels the transaction MEANWHILE the system ejects the
card.
• VALIDATES THAT = a condition is evaluated.
– Grammar
• VALIDATES THAT <condition>
– Explanation
• a condition is evaluated and must be true to proceed to the next step.
• the alternative case (the condition does not hold) must be described in a
corresponding alternative flow (BFS).
– Example:
• the system checks whether the user-entered PIN…
• the system VALIDATES THAT the user-entered PIN…

19
 Specifying a Use Case (cont.)

• DO … UNTIL = iteration.
– Grammar
• DO <steps> UNTIL <condition >
– Explanation
• Following keyword DO is a sequence of steps. Following keyword UNTIL is
a loop ending condition.
– Example:
1. DO
2. action1
3. action2
4. UNTIL condition
• ABORT = an exceptionally exit action.
– Grammar
• ABORT
– Explanation
• Used in alternative flows, iterative, and conditional logic sentences. It
means the ending of a use case.
• An alternative flow ends either with ABORT or RESUME STEP.
20
 Specifying a Use Case (cont.)

• RESUME STEP = an alternative flow goes back to its

corresponding basic flow.
– Grammar
• RESUME STEP <basic flow step #>
– Explanation
• Used in alternative flows.

21
 Software Requirements Elicitation and
Specifications
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

22
 <<include>>
• Used to:
– Decompose larger/longer use case
– Share functionalities
– The included use case is always triggered when the base use case
requires the included use case and is not optional
– The base use case delegates (sub)goals to the included use case
– indicates that the base use case includes the functionality of another
use case at a specific point or step in its flow of events.
– one use case explicitly includes the behavior of another use case
at a specified point within a course of action.
• Example:
– The use case ViewMap describes behavior that can be used by the
use case OpenIncident and the use case AllocateResources
OpenIncident <<include>>
Base Use
ViewMap
Case

AllocateResources <<include>>

23
 <<extend>>
• Problem:
– The functionality in the original problem statement needs to be
extended to account for exceptional flow of events.
• Solution:
– An extend association from (direction of the arrow head) a use case
A to a use case B indicates that use case A is an extension of use
case B.
– This specifies that use case A is triggered when use case B executes
only under some condition
• The extend relationship specifies that the incorporation of the extension
use case is dependent on what happens when the base use case
executes.
• The base use case implicitly includes the behavior (that's optional or
that occurs only under certain conditions) of another use case at one
or more specified points.
<<extend>>
ReportEmergency ConnectionDown

Base Use
Case
24
 Use Case Generalizations
• Generalization works the same way for use cases as it does for
classes
• A parent use case defines behavior that its children can inherit,
and the children can add to or override that behavior.
• Example Use Case Bellow shows use cases that describe three
different searches that a Customer can perform, all of which use
the basic search technique defined by the Perform Search use
case.
• This relationship is not used in most use case diagrams because
it can introduce unnecessary ambiguity

25
 Example I

<<extend>>
PlaceOrder PlaceRushOrder

<<include>>
ValidateUser

TrackOrder <<include>>

26
 Example II

Banking System

open_account Cash Dispenser

withdraw_cash
Clerk

Customer clear_checks

loan_application
Loan Officer

get_report

Manager

27
 Software Requirements Elicitation and
Specifications
• Fundamentals
– Motivation and Goals
– Requirement Engineering
– Functional vs. Non-Functional
– Defining Software System Scope
– Specifying a Use Case
– Use case relationships
– Pitfalls
• Requirements Elicitation Process

• Documentation

28
 Common mistake : Identifying wrong actor

• Consider a purchase system for any kind of store (Sears, Leons,

AMC Theatre, MacDonald’s). Customers give the cashier their
order. The cashier enters the selection ( the item’s bar code, the
selected movie, the number of Big Macs) and the system
calculates the total.

Customer Purchase System Cashier

Nowhere in the description above the customer
is said to interact with the system

• The customer gives payment (debit/credit card) and the

transaction is complete.

Customer Purchase System Cashier

29
 <<Include>>: Functional Decomposition
• Problem:
– A function in the original problem statement is too complex to be solvable
immediately
• Solution:
– Describe the function as the aggregation of a set of simpler functions. The
associated use case is decomposed into smaller use cases
ManageIncident

<<include>> <<include>>
<<include>>
CreateIncident HandleIncident CloseIncident

• However: remember the “one person, one sitting” test?

CreateIncident

HandleIncident

CloseIncident

30
 Discussion : <<include>> as Functional
Composition
A typical login situation
login

doX doX
<<include>>

doY login doY

<<include>>

<<include>>
doZ doZ

Neither is right or wrong.

Instead, they mean different things.

31
 In What Order Do Use Cases Execute?

• For each actor, we identify what that actor wants to do with the system.
– Each of these things that the actor wants to do with the system
become a Use Case.
– E.g., an actor wants to perform tasks A, B, C, and D with the system.
• This leads to 4 different use cases, all triggered by the actor.
• But perhaps, A is always being triggered before the other three?

• This cannot be modeled by a use case diagram!

• Solution: UML Activity diagram (Will be covered in future class)

– Activities are use cases.
– Activity diagram notation: conditions, loops, fork/join …

32
 Software Requirements Elicitation and
Specifications
• Fundamentals
• Requirements Elicitation Process

– Identifying actors
– Identifying scenarios
– Identifying use cases
– Identifying non-functional requirements
– Refining use cases
– Relationships between use cases
– Summary
• Documentation

33
 Use Case Model

• Define system functional requirements in terms of Actors and

Use Cases
– Each use case defined in terms of sequences of interactions
between Actor and System
• Structured narrative description
– Basic sequences
• Most common sequences of actions leading to success for the usecase
– Alternative sequences
• Error conditions, and other alternative flows
• Use case associations (include, extend)

34
Requirements Elicitation Activities- steps of
defining use cases
1. Identify actors
• Identify the different types of users of the future system
2. Identify scenarios
• Identify scenarios for typical functionalities
3. Identify use cases
• Abstract scenarios into use cases
4. Identify nonfunctional requirements
• Identify aspects visible to the user but not directly related to
functionalities
5. Refine use cases
• Is the system specification complete (e.g., exceptional conditions)
6. Identify relationships among use cases
• Consolidate the use case model by eliminating redundancies

35
 1. Identify Actors

• Can be human or external system, device

• Define system boundaries
• Find all stakeholders
• May correspond to roles in an organization
• Need to differentiate roles only when they access different
functionality
• Classes of functionality

36
 Questions to Ask

• Which user groups are supported by the system to perform their

work?
• Which user groups execute the system’s main functions?
• Which user groups perform secondary functions, such as
maintenance and administration?
• Will the system interact with any external hardware or software
system?

37
 FRIEND: Accident Management System

• It is a distributed information system for managing accidents. It

allows dispatchers and authorities to communicate and allocate
resources to an emergency.

FieldOfficer FRIEND Dispatcher

• Problem: Long list of potential actors

– Firefighters, police officers, dispatchers, investigators, …
• We need to consolidate the list into a small number of actors
who are different from the point of view of the system usage
– A firefighter and a field police officer share the same interface, both
involved with a single incident on the field
– Dispatcher manages multiple concurrent incidents and requires
access to more information

38
 2. Identify scenarios

Bridging the gap between the user and the developer

• Scenarios: Example of the use of the system in terms of a series
of interactions between an actor and the system
• Use cases: Abstraction that describes a class of scenarios (e.g.,
end user functionalities)

39
 Scenarios

• “A narrative description of what people do and experience

as they try to make use of computer systems and
applications” [M. Carrol, Scenario-based Design, Wiley, 1995]
• A concrete, focused, informal description of a single feature
of the system used by a single actor.
• Readily understandable by clients and users
• Developers and users write and refine a series of scenarios in
order to gain a shared understanding of what the system should
be.
– Iterative process.

40
 Heuristics for finding Scenarios

• Ask yourself or the client the following questions:

– What are the primary tasks that the system needs to perform?
– What data will the actor create, store, change, remove or add in the
system?
– What external changes / events does the system need to know
about?
– What changes or events will the actor of the system need to be
informed about?

• Insist on task observation if a system already exists

– Ask to speak to the end user, not just to the software contractor
– Expect resistance and try to overcome it

• Sources of information:
– User manuals of previous systems, procedure manuals, company
standards, user and client interviews

41
 FRIEND Scenario: Warehouse on Fire

• Scenario:
– A fire is detected in a warehouse; two field officers arrive at the scene and
request resources
• Source of information:
– Observation or discussions with actual, future users of the system about how
they would use the system (or are using the current system) in certain
circumstances
• Details:
– Bob, driving down main street in his patrol car notices smoke coming out of a
warehouse. His partner, Alice, reports the emergency from her car.
– Alice enters the address of the building, a brief description of its location (i.e.,
north west corner), and an emergency level. In addition to a fire unit, she
requests several paramedic units on the scene given that the area appears to
be relatively busy. She confirms her input and waits for an acknowledgment.
– John, the Dispatcher, is alerted to the emergency by a beep of his
workstation. He reviews the information submitted by Alice and acknowledges
the report. He allocates a fire unit and two paramedic units to the Incident site
and sends their estimated arrival time (ETA) to Alice.
– Alice received the acknowledgment and the ETA.

42
Observations about Warehouse on Fire Scenario

• Concrete scenario
– Describes a single instance of reporting a fire incident.
– Does not describe all possible situations in which a fire can be
reported.
• Participating actors
– Bob, Alice: Field officer (Primary Actor)
– and John, Dispatcher (Other stakeholder)

43
 FRIEND: Other Scenarios

• FenderBender:
– A car accident without casualties occurs on the highway.
– Police officers document the incident and manage traffic while the
damaged vehicles are towed away.
• Earthquake:
– An unprecedented earthquake seriously damages buildings and
roads, spanning multiple accidents and triggering the activation of the
statewide emergency operations plan.

Objective of defining scenarios:

– shared understanding of the user work processes that need to be
supported
– understanding of the scope of the system.
Next step: Scenarios have now to be formalized into use cases

44
 3. Identify Use Cases

• A scenario is an instance (or a realization) of a use case

• A use case specifies all possible scenarios for a given piece of
functionality
– Find hints for a use case in the scenario descriptions, e.g., “Report
Emergency “ in the first paragraph of the scenario is a candidate for
a use case
– Report Emergency accounts for all possible scenarios, i.e.,
Warehouse on fire, FenderBender, Earthquake etc.
• A use case is always initiated by an actor but may interact with
other actors as well
• A use case is a complete flow of events through the system

45
 Steps in Formulating a Use Case (I)

• First name the use case

– Use case name: ReportEmergency
• Then find the actors
– Generalize the concrete names (“Bob”) to participating actors (“Field
officer”)
– Participating Actors: ReportEmergency
• Field Officer (Initiator)
• Dispatcher
• Then concentrate on the flow of events
• Pre and post conditions

46
 Formulate the Flow of Events

1. The FieldOfficer activates the “Report Emergency” function on her

terminal.
2. FRIEND responds by presenting a form to the officer.
3. The FieldOfficer fills the form, by selecting the emergency level,
type, location, and brief description of the situation. The
FieldOfficer also describes possible responses to the emergency
situation. Once the form is completed, the FieldOfficer submits the
form
4. FRIEND receives the form and notifies the Dispatcher.
5. The Dispatcher reviews the submitted information and creates an
incident in the database by invoking the OpenIncident use case. The
Dispatcher acknowledges the emergency report and selects a
response.

47
 Entry and Exit Conditions

• Precondition:
– The FieldOfficer is logged into FRIEND
• Post-condition:
– Success-Post-condition: The FieldOfficer has received an
acknowledgement and the selected response from the Dispatcher,
OR
– Failure-Post-condition :The FieldOfficer has received an
explanation indicating why the transaction could not be processed

48
 Steps in formulating a use case (II)

• Write down the exceptions:

– The FieldOfficer is notified immediately if the connection
between her terminal and the central is lost.
– The Dispatcher is notified immediately if the connection between
any logged in FieldOfficer and the central is lost.
• Identify and write down any quality (NF) requirement:
– The FieldOfficer’s report is acknowledged within 30 seconds.
– The selected response arrives no later than 2 minutes after it is sent
by the Dispatcher.

49
 Writing Guidelines (I)

• Use cases should be named with verb phrases. The name of the
use case should indicate what the user is trying to accomplish
– e.g., ReportEmergency, OpenIncident.
• Actors should be named with noun phrases
– e.g., FieldOfficer, Dispatcher, Victim.
• The boundary of the system should be clear: Steps accomplished
by the actor and steps accomplished by the system should be
distinguished.
• Use case steps in the flow of events should be phrased in the
active voice. This makes it explicit who accomplished the step.

50
 Writing Guidelines (II)

• The causal relationship between successive steps should be clear.

• A use case should describe a complete user transaction
– e.g., the ReportEmergency use case describes all the steps between
initiating the emergency reporting and receiving an acknowledgement).
• A use case should not describe the user interface of the system.
This takes away the focus from the actual steps accomplished by the
user and is better addressed with visual mockups
– e.g., the ReportEmergency only refers to the “Report Emergency”
function, not the menu, the button, nor the actual command that corresponds
to this function.
• A use case should not be too long. Otherwise, use include and extends
relationships to decompose it in smaller use cases.

51
4. Identify Non-Functional (NF) Requirements

• User-visible aspects of the system that are not directly related to

the functional behavior of the system
• It is important to be systematic when eliciting quality
requirements.
• Use template questions.
– See examples on next slides.
– Standards (IEEE, DoD) also help with this.

• Template questions for:

– Usability
– Performance
– Reliability

52
 Template Questions for NF Requirements

Usability
• What is the level of expertise of the user?
• What are the user interface standards familiar to the user?
• What documentation should be provided to the user?

53
Template Questions for NF Requirements (II)

Performance
• How responsive should the system be?
• Are there user tasks that are time critical?
• How many concurrent users should it support?
• How large is a typical data store for comparable systems?
• What is the worse latency that is acceptable for users?

54
Template Questions for NF Requirements (III)

Reliability
• How reliable, available, robust should the system be?
• Is restarting the system acceptable in the event of a failure?
• How much data can the system loose?
• How should the system handle exceptions?
• Are there safety requirements on the system?
• Are there security requirements on the system?

55
 5. Refining Use Cases

• Precision, correctness and completeness and consistency

• Expect Use Cases to change a lot and have many iterations
• Scenarios and user interface mock-ups can be used to help
exploration and validation
• Links to other use cases (AllocateResources in FRIEND)
• ReportEmergency:
– Include details about the type of incident known to FRIEND
– Detail how the Dispatcher acknowledges the report of the
FieldOfficer

56
 Refinement Example (I)

1. The FieldOfficer activates the “Report Emergency” function on her

terminal.
2. FRIEND responds by presenting a form to the FieldOfficer. The
form includes an emergency type menu (general emergency, fire,
transportation), a location, incident description, resource request, and
hazardous material fields.
3. The FieldOfficer fills the form specifying minimally the emergency
type and description fields. The FieldOfficer may also describe
possible responses to the emergency situation and request specific
resources. Once the form is completed, the FieldOfficer submits
the form.
4. FRIEND receives the form and notifies the Dispatcher.

57
 Refinement Example (II)

5. The Dispatcher reviews the submitted information and creates an

incident in the database by invoking the OpenIncident use case. All
the information contained in the FieldOfficer’s form is
automatically included in the incident. The Dispatcher selects a
response by allocating resources to the incident (with the
AllocateResources use case) and acknowledges the emergency
report by sending a short message to the FieldOfficer.
6. The FieldOfficer receives the acknowledgment and the selected
response.

58
 Use Case Diagram for FRIEND

FRIEND

Open Incident
<<initiates>>

Field Officer Report Dispatcher

Emergency

Allocate
Resources

59
 6. Identify relationships among use cases

• Even simple systems have a lot of use cases

• Use case dependency = relationship between use cases
• Goal: Reduce complexity, Increase understandability, maximize reuse of
use cases
• Important relationships:
– Extend
• A use case extends another use case (separate exceptional and
common flows of events)
– Include
• A use case uses another use case (“functional decomposition”)
– Generalization

60
 Summary

• Scenarios and Use Cases is one way to document and formalize

requirements in a form which is understandable by users and
clients
• Scenarios are the basis to derive Use Cases
• Use Cases relationships can be used to simplify the use case
model: extend, include
• They are modeled as stereotypes of UML dependencies
• Other relationships could be imagined: sequential dependencies
…

61
 Tips

– A use case should describe the user’s interaction with the system,
not the computations the system performs.
– A use case should be written to be as independent as possible from
any particular user interface design.
• No: Push the Open button
• Yes: Choose the Open command.
– In general, a use-case should cover the full sequence of steps from
the beginning of a task until the end.
• Although use cases have been around for a while, there’s been little
standardization on their use. The UML is silent on the important contents
of a use case and has standardized only the much less important
diagrams. As a result, you can find a divergent range of opinions on use
cases.
• Do not overstructure the use case model.

62
 Advantages of using Use-Cases

• Helps define the scope of the system ( what it does and does not
do)
• Can be used as part of the development plan
– # use cases is an indicator of project size
– progress can be measured by % use cases completed
• Form the basis of definition of test cases
• Can be used to structure user manuals

63
 Disadvantages of Use-Cases

1) Use cases themselves must be validated

2) Some aspects of functional requirements may not be covered

by use case analysis, only those triggered by an actor.
– Automatic cleaning of a database to remove outdated information
may not appear in user’s use-case
– Solution: Have different packages of use-case, for different
stakeholders – user vs. maintainer.
3) When software requirements are derived from use-cases, the
software tends simply to mirror the way users worked BEFORE
the software was developed. Innovative solution may not be
considered.

64
 Software Requirements Elicitation and
Specifications
• Fundamentals
• Requirements Elicitation Process

• Documentation

65
 Requirements Definition document

• Defines system to be built from the customer’s perspective

• Customer needs to understand the document
• Basis of contract between customer and system developer
• Requirements ought to be complete and consistent!!!

66
 Software requirements document

• Cover page
• Introduction
• Functional requirements specification
• Nonfunctional requirements (e.g. standards to be met, platform,
memory requirements)
• Glossary

67
Software requirements document cover page

• Name of the project/product

• Date
• Version number
• Author(s)
• Responsibilities of every author
• Key changes since last version

68
 Format and Style

• Modifiability
– Well-structured, indexed, cross-referenced
– Little and explicit redundancy
• Traceability
– Backwards, e.g., stakeholder, document
– Forwards, e.g., to design, test plan
• Useful annotations: levels of necessity, stability

69
 Review - questions

• Important interfaces described?

• Major functions within scope?
• Design constraints realistic?
• Technological risk considered?
• Clear validation criteria stated?
• Do inconsistencies, omissions, redundancy exist?

70
 Review - guidelines

• Lookout for persuasive connectors (certainly, therefore,

obviously,….)
• Watch for vague terms (some, often, usually,….)
• Lists complete (no etc., such as,…)
• Check the use of terms: always the same meaning in document?
• Beware ambiguity and vague statements (e.g., undefined
terminology)

71
 Standards

• IEEE-STD-830-1993.
– IEEE Recommended Practice for Software Requirements
Specifications
• MIL-STD-498.
– Military Standard for Software Development and Documentation.
• DO-178B.
– Promotes traceability between high-level requirements down to code
statements (airborne systems)

Similar standards exist for public transportation (train), power plants

…

72