software requirement

As Management
requested it As the Project
Leader defined it
As Systems
designed it
As Programming
developed it
As Operations
installed it
What the
User wanted

Why Are Requirements Important?
• Top factors that caused project to fail
– Incomplete requirements
– Lack of user involvement
– Unrealistic expectations
– Lack of executive support
– Changing requirements and specifications
– Lack of planning
– System no longer needed
• Some part of the requirements process is involved in almost
all of these causes
• Requirements error can be expensive if not detected early

REQUIREMENT ENGINEERING
• Help software engineer to better understand
the problem they are trying to solve
1. What will be the business impact
2. What customer want
3. How end user interact with system

Process for Capturing Requirements/
Requirement Engineering Tasks
NEGOTIATIONS
SPECIFICATION
VALIDATIONELICITATIONINCEPTION
REQUIREMENTS
Management
ELABORATION

INCEPTION
• HOW DOES A SOFTWARE PROJECT GET
STARTED?

7
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

9
Inception Task
• During inception, the requirements engineer asks a set of questions to
establish…
– A basic understanding of the problem
– The people who want a solution
– The nature of the solution that is desired
– The effectiveness of preliminary communication and collaboration between the
customer and the developer
• Through these questions, the requirements engineer needs to…
– Identify the stakeholders
– Recognize multiple viewpoints
– Work toward collaboration
– Break the ice and initiate the communication

What are Stakeholders?
• Stakeholders are groups of people who have
an interest in a business organisation
• They can be seen as being either external to
the organisation,
or internal
• But some may be both!

Types of Stakeholder
• Owners (I)
• Shareholders (I)
• Managers (I)
• Staff or employees (I)
• Customers (E)
• Suppliers (E)
• Community (E)
• Government (E)
• I = Internal
• E = External

Internal and External Stakeholders
Internal stakeholders are those who are
‘members’ of the business organisation
• Owners and shareholders
• Managers
• Staff and employees
• External stakeholders are not part
of the firm

13
The First Set of Questions
• 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?
These questions focus on the customer, other stakeholders, the
overall goals, and the benefits

14
The Next Set of Questions
• How would you characterize "good" output that would be generated by
a successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the
solution will be used?
• Will special performance issues or constraints affect the way the
solution is approached?
These questions enable the requirements engineer to gain a better
understanding of the problem and allow the customer to voice his
or her perceptions about a solution

15
The Final Set of Questions
• Are you the right person to answer these questions? Are your answers
"official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?
These questions focus on the effectiveness of the
communication activity itself

16
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

17
Elicitation Task
• Eliciting requirements is the process of discovering the requirements for
the system by communicating with customer, system user and others who
have interest in the system being developed
• Eliciting requirements is difficult because of
1. Problems of scope in identifying the boundaries of the system or specifying
too much technical detail rather than overall system objectives
2. Problems of understanding what is wanted, what the problem domain is,
and what the computing environment can handle (Information that is believed
to be "obvious" is often omitted)
3. Problems of volatility because the requirements change over time
• Elicitation may be accomplished through two activities
– Collaborative requirements gathering
– Quality function deployment
– Work product
– Usage secnario

19
Basic Guidelines of Collaborative
Requirements Gathering
• Meetings are conducted and attended by both software engineers,
customers, and other interested stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important
points but informal enough to encourage the free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls the meeting
• A "definition mechanism" is used such as work sheets, flip charts, wall
stickers, electronic bulletin board, chat room, or some other virtual
forum
• The goal is to identify the problem, propose elements of the solution,
negotiate different approaches, and specify a preliminary set of
solution requirements

23
Quality Function Deployment
• This is a technique that translates the needs of the customer into
technical requirements for software
• It emphasizes an understanding of what is valuable to the customer
and then deploys these values throughout the engineering process
through functions, information, and tasks
• It identifies three types of requirements
– Normal requirements: These requirements are the objectives and goals
stated for a product or system during meetings with the customer
– Expected requirements: These requirements are implicit to the product
or system and may be so fundamental that the customer does not
explicitly state them
– Exciting requirements: These requirements are for features that go
beyond the customer's expectations and prove to be very satisfying when
present

24
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 (organized by function) and the domain
constraints that apply to each
• Any prototypes developed to better define requirements
The work products will vary depending on the system, but should
include one or more of the following items

• A set of preliminary usage scenarios (in the
form of use cases) that provide insight into the
use of the system or product under different
operating conditions

26
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

27
Elaboration Task
• During elaboration, the software engineer takes the information
obtained during inception and elicitation and begins to expand and
refine it
• Elaboration focuses on developing a refined technical model of
software functions, features, and constraints
• It is an analysis modeling task
– Use cases are developed
– Domain classes are identified along with their attributes and relationships
– State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional,
informational, and behavioral domains of the problem

28
Rules of Thumb
• The model should focus on requirements that are visible
within the problem or business domain. The level of
abstraction should be relatively high.
• Each element of the analysis model should add to an
overall understanding of software requirements and
provide insight into the information domain, function
and behavior of the system.
• Delay consideration of infrastructure and other non-
functional models until design.
• Minimize coupling throughout the system.
• Be certain that the analysis model provides value to all
stakeholders.
• Keep the model as simple as it can be.

29
Elements of the Analysis Model
Use-case diagrams
Activity Diagrams
Swim lane diagrams
Scenario-based
elements
Class diagrams
Analysis Packages
CRC Models
Collaboration Diagrams
Class-based elements
Data-flow diagrams
Control flowdiagrams
Processing narratives
Flow-oriented
elements
State diagrams
Sequence diagrams
Behavioral elements
Analysis
Model

Building analysis model
• Elements of analysis model
• Developing use case

31
Scenario-based
elements
Flow-oriented
elements
Behavioral elements
High level idea of the system from user’s or
a functional perspective
How information flows throughout the
system (data and control flow)
How the system responds to external stimuli
Static view of the system and how the
different parts are related. Tries to show
standard ideas of object oriented
development

32
• Scenario-based elements
– Describe the system from the user's point of view using
scenarios that are depicted in use cases and activity diagram
• Flow-oriented elements
– Use data flow diagrams to show the input data that comes into
a system, what functions are applied to that data to do
transformations, and what resulting output data are produced
• Class-based elements
– Identify the domain classes for the objects manipulated by the
actors, the attributes of these classes, and how they interact
with one another; they utilize class diagrams to do this
• Behavioral elements
– Use state diagrams to represent the state of the system, the
events that cause the system to change state, and the actions
that are taken as a result of a particular event; can also be
applied to each class in the system

33
Analysis Modeling Approaches
• Structural analysis:
– The data: The model defines their attributes and
relationships.
– The processes that transform the data: The model shows
how they transform the data objects as they flow through
the system.
• Object-oriented analysis:
– Focus: Classes and their inter-relationships
– UML is predominantly object-oriented

1. Use-case diagrams
2. Activity Diagrams
3. Swim lane diagrams
Scenario-based
elements

Use Cases
1. Use case diagrams are used to visualize, specify,
construct, and document the (intended) behavior of
the system, during requirements capture and
analysis.
1. Provide a way for developers, domain experts and
end-users to Communicate.
2. Serve as basis for testing.
3. Use case diagrams contain use cases, actors, and
their relationships.

36
Questions Commonly Answered by a
Use Case
• Who is the primary actor(s), the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the scenario begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the scenario 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?

• Step 1: Identify who is going to be using the
system directly. These are the Actors.

• Step 2: Define 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

• Step 3: For each of those Use Cases decide
on the most usual requirement when that
Actor is using the system. What normally
happens.

• Step 4: Describe that basic requirement in
the description for the use case.

• Step 5: Once you’re happy with the basic
requirement now consider the alternatives
and add those as extending use cases.
– Extend
– include

• Actors: A role that a user plays with respect to the
system, including human users and other systems. e.g.,
inanimate physical objects (e.g. robot); an external
system that needs some information from the current
system.
• Use case: A set of scenarios that describing an
interaction between a user and a system, including
alternatives.
• System boundary: rectangle diagram representing the
boundary between the actors and the system.

• Association: communication between an actor and a
use case; Represented by a solid line.

include
• A base use case is dependent on the included use
case(s); without it/them the base use case is
incomplete as the included use case(s) represent sub-
sequences of the interaction that may happen always
OR sometimes.
• The include relationship could be used:
– to simplify large use case by splitting it into several use
cases,
– to extract common parts of the behaviors of two or more
use cases.

• For example, the flow of events that occurs at
the beginning of every ATM use case (when
the user puts in their ATM card, enters their
PIN, and is shown the main menu) would be a
good candidate for an include.

Extend
• Extend is a directed relationship that specifies how and
when the behavior defined in usually supplementary
(optional) extending use case can be inserted into
the behavior defined in the extended use case.
• Extended use case is meaningful on its own, it
is independent of the extending use case. Extending use case
typically defines optional behavior that is not necessarily
meaningful by itself. The extend relationship is owned by the
extending use case. The same extending use case can extend
more than one use case, and extending use case may itself be
extended.

• The extension takes place at one or more extension
points defined in the extended use case.
• Extend relationship is shown as a dashed line with an open
arrowhead directed from the extending use case to
the extended (base) use case. The arrow is labeled with the
keyword «extend».

Bank ATM
Balance
enquiry
Withdrawal
Transfer
funds
Customer
bank
Maintenance
ATM Technician
CUSTOMER
AUTHENTICATION

Activity Diagram Symbols' Meaning
• The start symbol represents the beginning of a process
or workflow in an activity diagram. It can be used by
itself or with a note symbol that explains the starting
point.
• The activity symbol is the main component of an
activity diagram. These shapes indicate the activities
that make up a modeled process.
•The connector symbol is represented by arrowed lines
that show the directional flow, or control flow, of the
activity. An incoming arrow starts a step of an activity;
once the step is completed, the flow continues with the
outgoing arrow.
The end symbol represents the completion of a process
or workflow.

The join symbol, or synchronization
bar, is a thick vertical or horizontal line.
It combines two concurrent activities
and re-introduces them to a flow where
only one activity occurs at a time.
A fork is symbolized with multiple
arrowed lines from a join. It splits a
single activity flow into two concurrent
activities.
The decision symbol is a diamond
shape; it represents the branching or
merging of various flows with the
symbol acting as a frame or container.

1. Data-flow diagrams
2. Control flow diagrams
3. Processing narratives
Flow-oriented
elements

Data Flow Diagrams Symbols
Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
Logical Data Flow Diagrams – show the data
flow, structure, and requirements of a new
system
System Analysis and Design
System – a group of interrelated procedures
used for a business function, with an
identifiable boundary, working together for
some purpose.
Analysis – separation of a whole into its
component parts
Design – to create, fashion, execute, or
construct according to plan

Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
Source/Sink – help to establish the
boundaries of the system.
A source identifies the origin of data inflow
to the system.
A sink identifies the outflow of a system,
many times as information.
Sometimes referred to an entity, a source
may be a customer, vendor, employee, or
even another system. A single entity can be
both a source and a sink.

Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
Processes – are the activities (manual and
automated) that transform the inputs,
transport data from process to process,
stores the data, and produce the outputs of a
system.
Processes are used on every DFD starting
with an over all process on the context level
diagram, the system.

Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
DeMarco & Yourdon
Data Store – is the resting place of the data
in a system. A data store can be in the form
of paper, a disk file or any other media.
Normally the word ‘data’ does not appear in
the title of a data store. Some examples of
data stores are Customer Order, Payment,
Invoice, Time Card……

Source/
Sink
0.0
Process
DATA STORE
Data Flow Lines
Data Flow – is the data in motion.
− Data can move from the outside
(source) into a process.
−Once the inside of a system data must
flow from place to place through a
process, the flow lines show this
movement.
−The lines are labeled to provide clarity
and meaning to the data moving through
the system.

Creating Data Flow Diagrams
Steps:
1. Create a list of activities
2. Construct Context Level DFD
(identifies sources and sink)
3. Construct Level 0 DFD
(identifies manageable sub process )
4. Construct Level 1- n DFD
(identifies actual data flows and data stores )

• DFD can be partitioned into levels. Each
level has more information flow and data
functional details than the previous level.
• Highest level is Context Diagram. Some
important points are:
• 1 bubble (process) represents the entire
system.
• Data arrows show input and output.
• Data Stores NOT shown. They are within
the system.

A data flow diagram (DFD) of the scope of an organizational
system that shows the system boundaries, external entities
that interact with the system and the major information flows
between the entities and the system

Level 0 DFD
• Some important points are:
• Level 0 DFD must balance with the context
diagram it describes.
• Input going into a process are different from
outputs leaving the process.
• Data stores are first shown at this level.

A data flow diagram (DFD) that represents a system’s major
processes, data flows and data stores at a high level of
detail

Level 1
• Level 1 DFD must balance with the Level 0 it
describes.
• Input going into a process are different from
outputs leaving the process.
• Continue to show data stores.

1. Class diagrams
2. Analysis Packages
3. CRC Models
4. Collaboration Diagrams

1. State diagrams
2. Sequence diagrams
Behavioral elements

State Diagrams
• State Diagrams show the sequences of states
an object goes through during its life cycle in
response to stimuli, together with its responses
and actions; an abstraction of all possible
behaviors.

off
on
Lamp On
Lamp Off
off
on

79
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

80
Negotiation Task
• During negotiation, the software engineer
reconciles the conflicts between what the
customer wants and what can be achieved
given limited business resources

• Requirements are ranked (i.e., prioritized) by
the customers, users, and other stakeholders
• Risks associated with each requirement are
identified and analyzed
• Rough guesses of development effort are made
and used to assess the impact of each
requirement on project cost and delivery time
• Using an iterative approach, requirements are
eliminated, combined and/or modified so that
each party achieves some measure of
satisfaction

83
The Art of Negotiation
• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit

process pattern
• A process pattern
– describes a process-related problem that is encountered during
software engineering work,
– identifies the environment in which the problem has been
encountered, and
– suggests one or more proven solutions to the problem.

• Stated in more general terms, a process pattern provides you with a
template [Amb98]—a consistent method for describing problem
solutions within the context of the software process.
( defined at different levels of abstraction)
1. Problems and solutions associated with a complete process
model (e.g. prototyping).
2. Problems and solutions associated with a framework activity
(e.g. planning) or
3. an action with a framework activity (e.g. project estimating).

Pattern types
• Stage patterns—defines a problem associated with a
framework activity for the process. It includes
multiple task patterns as well.
For example, EstablishingCommunication would
incorporate the task pattern RequirementsGathering and
others.
• Task patterns—defines a problem associated with a
software engineering action or work task and relevant
to successful software engineering practice
• Phase patterns—define the sequence of framework
activities that occur with the process, even when the
overall flow of activities is iterative in nature.
Example includes SprialModel or Prototyping.

Example of process pattern
• Describes an approach that may be applicable when
stakeholders have a general idea of what must be done but
are unsure of specific software requirements.
• Pattern name. RequiremetnsUnclear
• Intent. This pattern describes an approach for building a
model that can be assessed iteratively by stakeholders in an
effort to identify or solidify software requirements.
• Type. Phase pattern

• Initial context. Conditions must be met (1)
stakeholders have been identified; (2) a
mode of communication between
stakeholders and the software team has
been established; (3) the overriding software
problem to be solved has been identified by
stakeholders ; (4) an initial understanding
of project scope, basic business
requirements and project constraints has
been developed.
• Problem. Requirements are hazy or

• Resulting context. A software prototype that identifies
basic requirements. (modes of interaction, computational
features, processing functions) is approved by
stakeholders. Following this, 1. This prototype may evolve
through a series of increments to become the production
software or 2. the prototype may be discarded.
• Related patterns. CustomerCommunication,
IterativeDesign, IterativeDevelopment,
CustomerAssessment, RequirementExtraction.

Analysis Pattern
• Suggests solutions within the application
domain that can be reused when modelling
many application
• They are integrated into analysis model by
reference to the pattern name
• They are stored in a repository so that
requirements engineer can use search facilities
to find and apply them

91
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

92
Specification Task
• A specification is the final work product produced by the
requirements engineer
• It is normally in the form of a software requirements specification
• It serves as the foundation for subsequent software engineering
activities
• It describes the function and performance of a computer-based
system and the constraints that will govern its development
• It formalizes the informational, functional, and behavioral
requirements of the proposed software in both a graphical and
textual format

93
Typical Contents of a Software
Requirements Specification
• Requirements
– Required states and modes
– Software requirements grouped by capabilities (i.e., functions, objects)
– Software external interface requirements
– Software internal interface requirements
– Software internal data requirements
– Other software requirements (safety, security, privacy, environment,
hardware, software, communications, quality, personnel, training, logistics,
etc.)
– Design and implementation constraints
• Qualification provisions to ensure each requirement has been met
– Demonstration, test, analysis, inspection, etc.
• Requirements traceability
– Trace back to the system or subsystem where each requirement applies

Non functional requirements
Performance
requir ements
Space
requir ements
Usability
requir ements
Efficiency
requir ements
Reliability
requir ements
Portability
requir ements
Inter oper ability
requir ements
Ethical
requir ements
Legislative
requir ements
Implementa tion
requir ements
Standar ds
requir ements
Delivery
requir ements
Safety
requir ements
Privacy
requir ements
Product
requir ements
Organisational
requir ements
External
requir ements
Non-functional
requir ements

Requirements Documentation
IEEE Standard for SRS Organized by Objects
1.Introduction to the Document
1.1 Purpose of the Product
1.2 Scope of the Product
1.3 Acronyms, Abbreviations, Definitions
1.4 References
1.5 Outline of the rest of the SRS
2.Overall Description of Product
2.1 Product perspective
2.1.1 system interface
2.1.2 User interface
2.1.3 Hardware Interfaces
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and Dependencies

3.Specific Requirements
3.1 External Interface Requirements
3.1.1 User Interfaces
3.1.3 Software Interfaces
3.1.4 Communications Interfaces
3.2 Functional Requirements
3.2.1 sequence diagram
3.2.2 Class 2
…
3.3 Performance Requirements
3.4 software system attribute
3.4.1Relability
3.4.2 Avaliability
3.5 Quality Requirements
3.6 Other Requirements
4. Supporting information
4.1 Appendices

1.3 Acronyms, Abbreviations,
Definitions
1.4 References
1.5 Outline of the rest of the
SRS

110
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

111
Validation Task
• During validation, the work products produced as a result of
requirements engineering are assessed for quality
• The specification is examined to ensure that
– all software requirements have been stated unambiguously
– inconsistencies, omissions, and errors have been detected and corrected
– the work products conform to the standards established for the process,
the project, and the product
• The formal technical review serves as the primary requirements
validation mechanism
– Members include software engineers, customers, users, and other
stakeholders

113
Questions to ask when Validating
Requirements
• Is each requirement consistent with the overall objective for the
system/product?
• Have all requirements been specified at the proper level of
abstraction? That is, do some requirements provide a level of
technical detail that is inappropriate at this stage?
• Is the requirement really necessary or does it represent an add-on
feature that may not be essential to the objective of the system?
• Is each requirement bounded and unambiguous?
• Does each requirement have attribution? That is, is a source
(generally, a specific individual) noted for each requirement?
(more on next slide)

114
Questions to ask when Validating
Requirements (continued)
• Do any requirements conflict with other requirements?
• Is each requirement achievable in the technical environment that will
house the system or product?
• Is each requirement testable, once implemented?
– Approaches: Demonstration, actual test, analysis, or inspection
• Does the requirements model properly reflect the information, function,
and behavior of the system to be built?
• Has the requirements model been “partitioned” in a way that exposes
progressively more detailed information about the system?

Validation Walkthroughs
Readings
Interviews
Reviews
Checklists
Models to check functions
and relationships
Scenarios
Prototypes
Simulation
Formal inspections
Verification
Checking
Cross-referencing
Simulation
Consistency checks
Completeness checks
Check for unreachable states
of transitions
Model checking
Mathematical proofs

116
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification

117
Requirements Management Task
• During requirements management, the project team performs a set of
activities to identify, control, and track requirements and changes to
the requirements at any time as the project proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more traceability tables
• These tables may be stored in a database that relate features,
sources, dependencies, subsystems, and interfaces to the
requirements
• A requirements traceability table is also placed at the end of the
software requirements specification

Requirements Documentation
IEEE Standard for SRS Organized by Objects
1.3 Acronyms, Abbreviations,
Definitions
1.4 References
1.5 Outline of the rest of the SRS
2.Overall Description of Product
2.1 Product perspective
2.1.1 system interface
2.1.2 User interface
2.2 Product Functions
2.3 User Characteristics
2.4 Constraints
2.5 Assumptions and
Dependencies
3.Specific Requirements
3.1 External Interface
Requirements
3.1.1 User Interfaces
3.1.3 Software Interfaces
3.1.4 Communications
Interfaces
3.2 Functional Requirements
3.2.1 Class 1
3.2.2 Class 2
…
3.3 Performance Requirements
3.4 Design Constraints
3.5 Quality Requirements
3.6 Other Requirements
4.Appendices

119
Summary
Requirements
Management
Validation
Inception
Elicitation
Elaboration
Negotiation
Specification


software requirement

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie software requirement

Ähnlich wie software requirement (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

software requirement