The document summarizes key aspects of system engineering and requirements engineering processes. It discusses how system engineering occurs as a consequence of defining computer-based systems and their elements. It also explains the different levels of abstraction in requirements engineering from inception to specification and management. Example techniques for eliciting requirements like use cases and collaborative meetings are also outlined.

1. Chapt er 6
Syst em Engineer ing
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman
1

2. Syst em Engineer ing
 Software Engineering occurs as a
consequence of a process called system
engineering.
 System engineering process takes on
different forms depending on the application
domain in which it is applied.
1 Business Process engineering
2 Product engineering
2

3. The
Hier ar chy
Business or
Product Dom
ain
World view
Dom
ain of interest
Dom
ain view
System elem
ent
Elem
ent view
Detailed view
3

4. Pr oduct Engineer ing
The complete
product
System analysis
(World view)
capabilities
hardware
Component
engineering
( Domain view)
software
P rocessing requirement
data
function
behavior
Analysis & Design
M odeling
(Element view)
program
component
Software
E ngineering
Construction
&
Integration
(Detailed view)
4

5. Syst em Engineer ing Cont .
 Definition of Computer based system: A
set or arrangement of elements that are
organized to accomplish some predefined
goal by processing information.
 Elements of computer based system:
1. Software
2. Hardware
3. People
4. Documentation
5. Database
6. Procedures
5

6. Chapt er 7
Requir ement s Engineer ing
Software Engineering: A Practitioner’s Approach, 6th edition
by Roger S. Pressman
6

7. Requir ement s Engineer ing
 Requirement: A
function, constraint or other property
that the system must provide to fill the needs of the
system’s intended user(s)
 Engineering:
implies that systematic and repeatable
techniques should be used to ensure that system
requirements are complete, consistent, relevant . . .
etc.
 Requirement Engineering covers all of the activities
involved in discovering, documenting, and
maintaining a set of requirements for a system.
 RE means that requirements for a product are
defined, managed and tested systematically
7

8. Requir ement s Engineer ing
Requirement engineering process is accomplished through the
execution of seven distinct functions:
Inception—Establish a basic understanding of the problem and
the nature of the solution.
Elicitation—Draw out the requirements from stakeholders.
Elaboration—Create an analysis model that represents
information, functional, and behavioral aspects of the
requirements.
Negotiation—Agree on a deliverable system that is realistic for
developers and customers.
Specification—Describe the requirements formally or informally.
Validation—Review the requirement specification for errors,
ambiguities, omissions, and conflicts.
8
Requirements management—Manage changing requirements.

9. I ncept ion
 Ask “context-free” questions










Who is behind the request for this work?
Who will use the solution (product/system)?
What will be the economic benefits?
How would you characterize “good” output from the
system?
What problems does this solution address?
What environment will the product be used in?
Are you the right person to answer these questions?
Are these question relevant?
Can anyone else provide additional information?
Should I be asking you anything else?
9

10. Get t ing Requir ement s Right
 “The hardest single part of building a software system is
deciding what to build. No part of the work so cripples the
resulting system if done wrong. No other part is more difficult to
rectify later.”
—Fred Brooks
 “The seeds of major software disasters are usually sown within
the first three months of commencing the software project.”
—Capers Jones
 “We spend a lot of time—the majority of project effort—not
implementing or testing, but trying to decide what to build.”
—Brian Lawrence
10

11. Elicit ing Requir ement s
 Why is it so difficult to clearly understand what the customer wants?
 Problems of Scope
 The boundary of the system is ill-defined.
 Customers/users specify unnecessary technical detail that may confuse
rather than clarify objectives.
 Problems of understanding
 Customers are not completely sure of what is needed.
 Customers have a poor understanding of the capabilities and limitations of
the computing environment.
 Customers don’t have a full understanding of their problem domain.
 Customers have trouble communicating needs to the system engineer.
 Customers omit detail that is believed to be obvious.
 Customers specify requirements that conflict with other requirements.
 Customers specify requirements that are ambiguous or untestable.
 Problems of Volatility
 Requirements change over time.
11

12. Elabor at ion, Negot iat ion
 Information obtained from the customer
during inception and elicitation is expanded
and refined during elaboration.
 The end result of elaboration is an analysis
model that defines the informational,
functional, and behavioral domain of the
problem.
 Requirement engineer reconcile the conflicts if
any through the process of negotiation.
12

13. Specif icat ion, Validat ion
 Specification means different things to different
people.
 Specification can be a written document, a set of
graphical models, a formal mathematical model, a
collection of usage scenarios, a prototype, or any
combination of these.
 Work products produced as a consequence of
requirements engineering are assessed for quality
during validation step.
 Primary requirement validation mechanism is the
formal technical review.
13

14. Requir ement s Management
 Requirement management is a set of
activities that help the project team identify,
control, and track requirements and changes
to requirements at any time as the project
proceeds.
14

15. I nit iat ing t he Requir ement s
Engineer ing Pr ocess
 To get the project started in a way that
will keep it moving forward toward a
successful solution.
 Identifying the stakeholders
 Recognizing Multiple Viewpoints
 Working toward Collaboration
 Asking the first questions
15

16. Elicit ing Requir ement s
 Various approaches can be taken into
consideration like
•
•
•
•
Collaborative Requirements Gathering
Quality Function Deployment
User Scenarios
Elicitation Work Products
16

17. What ar e t he basic guidelines f or conduct ing
a collabor at ive r equir ement s gat her ing
meet ing?
 Meetings are conducted and attended by all interested stakeholders.
 Rules for preparation and participation are established.
 Agenda should be formal enough to cover all important points, but
informal enough to encourage the free flow of ideas.
 A facilitator (can be customer, a developer, or an outsider) controls
the meeting.
 A definition mechanism (blackboard, flip charts, etc.) is used.
 During the meeting:





The problem is identified.
Elements of the solution are proposed.
Different approaches are negotiated.
A preliminary set of solution requirements are obtained.
The atmosphere is collaborative and non-threatening.
17

18. Qualit y Funct ion Deployment
 Quality function deployment is a technique that
translates the needs of the customer into technical
requirements for software.
 QFD identifies three types of requirements
 Normal requirements: reflect objectives and goals
stated for a product
 Expected requirements: are implicit to the product
or system and may be so fundamental that the
customer does not explicitly state them.
 Exciting requirements: reflect features that go
beyond the customer’s expectations and prove to
be very satisfying when present.
18

19. User Scenar ios
 It is difficult to move into more technical
software engineering activities until the
software team understands how these
functions and features will be used by
different classes of end users.
 To accomplish this, developers and
users create a set of scenarios often
called use-cases.
19

20. Elicit at ion Wor k
Pr oduct s
 What information is produced as a consequence of
requirements gathering?
•
•
•
•
•
Statement of need and feasibility.
Bounded Statement of scope.
List of participants in requirements elicitation.
Description of the system’s technical environment.
List of requirements and associated domain
constraints.
• List of usage scenarios.
• Any prototypes developed to refine requirements.
20

21. Developing Use-Cases
 A use-case scenario is a story about how someone or something
external to the software (known as an actor) interacts with the system.
 Each scenario answers the following questions:
•
Who is the primary actor, the secondary actor(s)?







What are the actor’s goals?
What preconditions should exist before the story begins?
What main tasks or functions are performed by the actor?
What exceptions might be considered as the story is described?
What variations in the actor’s interaction are possible?
What system information will the actor acquire, produce, or change?
Will the actor have to inform the system about changes in the external
environment?
 What information does the actor desire from the system?
 Does the actor wish to be informed about unexpected changes?
21

22. Use-Case Diagr am
22

23. Element s of t he Analysis
Model
 Scenario-based elements
 Use-case—How external actors interact with the
system (use-case diagrams; detailed templates)
 Functional—How software functions are processed in
the system (flow charts; activity diagrams)
 Class-based elements
 The various system objects (obtained from scenarios)
including their attributes and functions (class diagram)
 Behavioral elements
 How the system behaves in response to different
events (state diagram)
 Flow-oriented elements
 How information is transformed as if flows through the
system (data flow diagram)
23

24. Act ivit y Diagr am f or RE
24

25. Class Diagr am
25

26. St at e Diagr am
26

27. Analysis Pat t er ns
Pattern name: Captures the essence of the pattern.
Intent: What the pattern accomplishes or represents.
Motivation: A scenario that illustrates how the pattern solves a problem.
Forces and context: External issues (forces) that affect how the pattern is
used, and external issues resolved when the pattern is applied.
Solution: How the pattern is applied to solve the problem; emphasizes
structural and behavioral issues.
Consequences: What happens when the pattern is applied; what trade-offs
exist during its application.
Design: How the pattern can be achieved via known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: Patterns related to the named pattern because
(1) they are commonly used with the named pattern;
(2) they are structurally similar to the named pattern;
(3) they are a variation of the named pattern.
27

28. Negot iat ing Requir ement s
 Identify the key stakeholders
 These are the people who will be involved in the
negotiation
 Determine each of the stakeholders “win
conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that lead to
“win-win”
28

29. Validat ing Requir ement s
 Is each requirement consistent with the objective of the
system?
 Have all requirements been specified at the proper level of
abstraction?
 Is the requirement really necessary?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution?
 Do any requirements conflict with other requirements?
 Is each requirement achievable in the system’s technical
environment?
 Is each requirement testable, once implemented?
 Does the model reflect the system’s information, function and
behavior?
29


30. Example CRG Meet ing
 First CRG meeting of the SafeHome project.
 After Q&A session (inception meeting), stakeholders write a
two page product request, which is delivered to those
attending the first CRG meeting.
 Attendees are asked to make a rough list of objects,
services, constraints, and performance criteria for the
product.
 At the meeting, a combined list is created in each topic.
 Subgroups write mini-specifications for each list item.
 Relevant features in mini-specifications are added to the list.
30

31. Example CRG Meet ing
 Our research indicates that the market for home management
systems is growing at a rate of 40 percent per year. The first
SafeHome function we bring to market should be the home
security function. Most people are familiar with “alarm systems”
so this would be an easy sell.
 The home security function would protect against and/or
recognize a variety of undesirable “situations” such as illegal
entry, fire, flooding, carbon monoxide levels, and others. It’ll use
our wireless sensors to detect each situation, can be
programmed by the homeowner, and will automatically
telephone a monitoring agency when a situation is detected.
31

32. Example CRG Meet ing
 Objects – control panel, smoke detectors, window and door
sensors, motion detectors, an alarm, an event (sensor has been
activated), a display, a PC, telephone numbers, a telephone
call, …
 Services – configuring the system, setting the alarm, monitoring
the sensors, dialing the phone, programming the control panel,
reading the display, …
 Constraints – System must recognize when sensors are not
operating, must be user friendly, must interface directly to a
standard phone line, …
 Performance criteria – Sensor event should be recognized within
one second, an event priority scheme should be implemented,
…
32

33. Example CRG Meet ing
 Mini-specification for Control Panel
 The Control Panel is a wall-mounted unit
that is approximately 9 x 5 inches in size.
The control panel has wireless connectivity
to sensors and a PC. User interaction
occurs through a keypad containing 12
keys. A 2 x 2 inch LCD display provides
user feedback. Software provides
interactive prompts, echo, and similar
functions.
33