Transcript Transparency Masters for Software Engineering: A

7.1 A Bridge to Design & Construction



Is requirements engineering necessary?
Are there ever cases/situations where requirements
engineering can be skipped? (Brad)
Why do some software developers not pay enough
attention to requirements engineering?
1
7.2 Requirements Engineering Tasks
1.
2.
3.
4.
5.
6.
7.


Inception—ask a set of questions that establish a basic understanding of
the problem, the people, the solution, the effectiveness of communication
Elicitation—elicit requirements from all stakeholders
Elaboration—create an analysis model that identifies data, function and
behavioral requirements
Negotiation—agree on a deliverable system that is realistic for developers
and customers
Specification—can be a document, model, user scenarios, prototype, etc.
Validation—a review mechanism that looks for errors, inconsistencies,
unrealistic requirements.
Requirements management
Which of the 7 requirement engineering steps (Inception, Elicitation,
Elaboration, Negotiation, Specification, Validation, Requirement
Management) is most prone to failure? Why? (Brad)
Failure in which requirement engineering step would be most likely
to cause the project to fail? (Brad)
2
7.3 Inception


Identify stakeholders
Recognize multiple points of view



Work toward collaboration
The first questions







Should a software developer ever choose to ignore a stakeholder
viewpoint that s/he believes would hurt the quality of a project? If
so, what would be an ethical solution to this problem?
Who is behind the request for this work?
Who will use the solution?
What will be the economic benefit of a successful solution
Is there another source for the solution that you need?
What types of questions should be asked during the Inception
phase? What types of questions should be avoided? (Brad)
What are some other “context-free” questions that you might ask
a stake holder during inception?
What does “feasibility analysis” imply when it is discussed within
the context of the inception function?
3
7.4 Eliciting Requirements:
Collaborative Requirements Gathering







meetings are conducted and attended by both software
engineers and customers
rules for preparation and participation are established
an agenda is suggested
a "facilitator" controls the meeting
a "definition mechanism" is used
the goal is to identify the problem, propose elements of the
solution, negotiate different approaches, and specify a
preliminary set of solution requirements.
Difficult due to:
 Problems of scope
 Problems of understanding
 Problems of volatility
4
7.4 Eliciting Requirements





How involved should developers be in the Elicitation
phase? (Brad)
What are the benefits & consequences of having developers
actively involved in the Elicitation phase? (Brad)
In addition to the problems of scope, understanding, and
volatility, what other significant issues would a requirements
engineer face during elicitation?
At what point during requirements engineering is acceptance
risk the highest? At what point is it the lowest? What steps
can a software developer take to minimize this risk?
You have been given the responsibility to elicit requirements
from a customer who tells you s/he is too busy to meet with
you. What should you do?
5
7.4 Eliciting Requirements :
Quality Function Deployment

Function deployment determines the “value” (as
perceived by the customer) of each function required of
the system





Normal requirements
Expected requirements
Exciting requirements
What are the dangers of "Expected" and "Exciting"
requirements? (Brad)
What “obvious” information about a system is a
stakeholder or end-user likely to omit from the list of
requirements?
6
7.4 Eliciting Requirements

Elicitation Work Products:







a statement of need and feasibility.
a bounded statement of scope for the system or product.
a list of customers, users, and other stakeholders who
participated in requirements elicitation
a description of the system’s technical environment.
a list of requirements (preferably organized by function) and
the domain constraints that apply to each.
a set of usage scenarios that provide insight into the use of
the system or product under different operating conditions.
any prototypes developed to better define requirements.
7
7. 5 Developing Use-Cases






A collection of user scenarios that describe the thread of
usage of a system
Each scenario is described from the point-of-view of an
“actor”—a person or device that interacts with the
software in some way
An actor and an end-user are not necessarily the same.
What features compose an effective use-case?
Should stakeholders be asked to develop use-cases on
their own for a project?
Do any problems arise from using use-cases as part of
the requirements engineering process?
8
Use-Case Diagram
Arms/ disarms
syst em
Accesses syst em
via Int ernet
sensors
homeow ner
Responds t o
alarm event
Encount ers an
error condit ion
syst em
administ rat or
Reconf igures sensors
and relat ed
syst em f eat ures
9
7.6 Building the Analysis Model

Elements of the analysis model

Scenario-based elements




Class-based elements



Implied by scenarios
Class diagram
Behavioral elements


Functional—processing narratives for software functions
Use-case—descriptions of the interaction between an
“actor” and the system
Use case diagram, activity diagram
State diagram
Flow-oriented elements

Data flow diagram
10
Activity Diagram
Conduct FA ST
m eet ings
Make list s of
f unc t ions , c las s es
Mak e lis t s of
c onst raint s , et c.
f orm al priorit izat ion?
El i c i t re q u i re m e n t s
no
y es
Use QFD t o
priorit ize
requirem ent s
def ine act ors
inf orm ally
priorit iz e
requirem ent s
draw use-c as e
diagram
writ e sc enario
Creat e Us e-cas es
c om plet e t em plat e
11
Class Diagram
From the SafeHome system …
Sensor
name/ id
ty pe
locat ion
area
characterist ics
ident if y()
enable()
disable()
reconf igure()
12
State Diagram
Reading
commands
Init ializat ion
t urn copier
“on“
syst em st at us=“not ready”
display msg = “please wait ”
display st at us = blinking
subsyst ems
ready
ent ry/ swit ch machine on
do: run diagnost ics
do: init iat e all subsyst ems
not jammed
syst em st at us=“Ready”
display msg = “ent er cmd”
display st at us = st eady
paper f ull
ent ry/ subsyst ems ready
do: poll user input panel
do: read user input
do: int erpret user input
t urn copier “of f ”
st art copies
Making copies
copies complet e
syst em st at us=“Copying”
display msg= “copy count =”
display message=#copies
display st at us= st eady
ent ry/ st art copies
do: manage copying
do: monit or paper t ray
do: monit or paper f low
paper t ray empt y
paper jammed
problem diagnosis
syst em st at us=“Jammed”
display msg = “paper jam”
display message=locat ion
display st at us= blinking
load paper
syst em st at us=“load paper”
display msg= “load paper”
display st at us= blinking
ent ry/ paper empt y
do: lower paper t ray
do: monit or f ill swit ch
do: raise paper t ray
not jammed
ent ry/ paper jammed
do: det ermine locat ion
do: provide correct ivemsg.
do: int errupt making copies
Figure 7.6 Preliminary UML st at e diagram for a phot ocopier
13
7.6 Building the Analysis Model



Is the analysis model an effective way to
describe system requirements? Why or why not?
Why would it be advantageous to use different
modes of representation (e.g. Use Cases, Flow
Charts, computer based tools) while building the
analysis model? (Brad)
Why are analysis models considered a "snapshot
of the system in time"? (Brad)
14
7.7 Negotiating Requirements

Identify the key stakeholders


Determine each of the stakeholders “win conditions”




Win conditions are not always obvious
Negotiate


These are the people who will be involved in the negotiation
Work toward a set of requirements that lead to “win-win”
How can a systems developer resolve disputes effectively during
negotiation?
Let’s assume that you’ve convinced the customer (you’re a very good
salesperson) to agree to every demand you have as a developer. Is
that always a good thing? (Brad)
What does “win-win” mean in the context of negotiation during the
requirements engineering activity?
15
7.8 Validating Requirements

Examine each element of the analysis model for
consistency, omissions, and ambiguity.

What steps can be maximize the effectiveness of
requirements validation? (Brad)
Do a majority of successful software projects spend a
considerable about of time on requirements validation?
How much time should be spent on this step?
If requirements are not consistently stated, how long will it
take for problems to occur?



What are the benefits of requirement specification
templates/documents? What are the drawbacks?
16