Professional Documents
Culture Documents
Analysis Concepts and Principles Pressman Sommerville
Analysis Concepts and Principles Pressman Sommerville
Chapter 11 Pressman
Chapter 4 Sommerville
1
• The Requirements phase is in which the
requirements for the software are:
– gathered and analyzed, to produce a
complete and unambiguous specification of
what the software is required to do.
2
Requirements engineering
• The process of establishing the services that
the customer requires from a system and the
constraints under which it operates and is
developed
3
Software Requirements
• A software requirement is a feature, function,
capability or property that a software product
must have
• It may range from a highlevel abstract statement
of a service or of a system constraint to a detailed
mathematical functional specification
• Software Design
– A software design is a specification of a
software system that programmers can
implement in code.
4
• Requirements definition
– A statement in natural language plus
diagrams of the services the system
provides and its operational constraints.
• Requirements specification
– A structured document setting out detailed
descriptions of the system services. Written
as a contract between client and contractor
5
Dr Romana Aziz MCS-NUST 6
What vs How
• The traditional way to distinguish
requirements from design:
– What a system is supposed to do is
requirements
– How a system is supposed to do it is design
7
Requirements vs Design
• Requirements state client needs and solution
constraints.
• Designs state problem solutions.
• Determining requirements is really the first
step of design.
8
Requirements Phase Activities
• Problem or requirements analysis: Working
with clients to understand their needs and the
constraints on solutions
• Requirements Specification: Documenting the
requirements
• These activities are logically distinct but
usually occur together.
9
The requirements engineering process
• Feasibility study
– Find out if the current user needs be
satisfied given the available technology and
budget?
• Requirements analysis
– Find out what system stakeholders require
from the system
10
• Requirements definition
– Define the requirements in a form
understandable to the customer
• Requirements specification
– Define the requirements in detail
11
Requirements analysis
• Involves technical staff working with
customers to find out about the application
domain, the services that the system should
provide and the system's operational
constraints
• May involve endusers, managers, engineers
involved in maintenance, domain experts,
trade unions, etc. These are called
stakeholders
12
Problems of requirements analysis
• Stakeholders don't know what they really want
• Stakeholders express requirements in their
own terms
• Different stakeholders may have conflicting
requirements
• Organisational and political factors may
influence the system requirements
• The requirements change during the analysis
14
Problem: Requirements Volatility
• If requirements change during development,
complexity increases and productivity drops,
but bad requirements can be fixed and
changing customer needs met.
• If requirements are frozen in development,
the product is produced more quickly and
cheaply, but may not meet customer needs.
15
Software Requirements Specification
• A software requirements specification (SRS)
document is a statement of all the
requirements for a software product.
16
Role of the SRS
17
Problem: Requirements Elicitation
• Eliciting requirements is difficult because:
– It is often not clear who the users are
– Different customers want different things
– Customers don’t know what they want
– Engineers don’t understand the customers’
domain, so they can’t understand the
customers
– Customers don’t understand computing
technology, so they can’t understand the
engineers
18
– Engineers are not trained to elicit
requirements
– Requirements elicitation is a big job–
everyone usually get tired of it, or run out
of time and money for it, before it is
really done
19
Problem: Language
• Natural language is expressive and
understood by customers and developers, but
it is imprecise and wordy.
• Formal language is precise and concise and
may be amenable to formal analysis, but it is
inexpressive and difficult to understand.
20
Analysis Concepts and Principles
• Requirements Analysis
– The first technical step in the software
engineering process
• It is a process of
– discovery
– refinement
– modeling
– specification
– Both developer and customer take an active
role
21
Requirements Analysis
• Areas of Effort
– Problem Recognition
– study system specification and project
plan
– communication for analysis
– recognition of the basic problem
elements as perceived by the
user/customer
22
– Problem Evaluation and Solution Synthesis
– focus on “what”
– data objects, info flow, functions, behavior,
interface, constraints
– architecture for implementation
– Modeling
– Specification
– Review
– prototyping
23
Communication techniques
• Initiating the Process
– conduct a preliminary meeting or interview
• Context-Free Questions
– focus on customer, goals, and benefits
– example
– Who is behind request for work?
– Who will use solution?
– What are Economic Benefits of successful
solution?
– Is there an alternate source for solution?
24
Preliminary Meeting/Interview
• Focus on Problem and Solution
– What are characteristics of “good output”?
– What problem(s) will this solution address?
– What is the environment where solution will
be used?
– Are there special Performance Issues or
Constraints?
25
Preliminary Meeting/Interview
• Focus on the Effectiveness of the Meeting
– Are you the right person to answer these questions?
– Are your answers “official”?
– Are my questions relevant to problem?
– Am I asking too many questions?
– Is there anyone else who can provide more
information?
– Is there anything else I should be asking you?
26
Next Lecture
• Feasibility
– purpose
– document
– Activities
– Problems
• Communication Techniques
– FAST
– QFD
27