Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 27

Analysis Concepts and Principles

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 high­level 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 end­users, 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

Dr Romana Aziz MCS-NUST 13


Requirements Phase Problems
• The requirements phase is HARD! There are
several reasons for this:
– requirements volatility
– requirements elicitation problems
– language problems
– requirements traceability problems

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

1. Drives the rest of the life cycle


2. Forces good problem analysis
3. Serves as an agreement between customers
and developers about the delivered product

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

You might also like