Scribd
Upload
43 views19 pages

9 - Requirement Engineering Process

The document discusses the requirements engineering process, including requirements elicitation, analysis, specification, and validation. It describes the four phases of requirements engineering and notes some common means of eliciting requirements like interviewing stakeholders. The importance of writing requirements that are clear, traceable, and testable is also covered. Finally, it addresses the Software Requirements Specification document and some considerations for its format and content.

Uploaded by

ishishahid4
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
43 views19 pages

9 - Requirement Engineering Process

The document discusses the requirements engineering process, including requirements elicitation, analysis, specification, and validation. It describes the four phases of requirements engineering and notes some common means of eliciting requirements like interviewing stakeholders. The importance of writing requirements that are clear, traceable, and testable is also covered. Finally, it addresses the Software Requirements Specification document and some considerations for its format and content.

Uploaded by

ishishahid4
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 19

Software Engineering

Topic # 9 – Requirements Engineering Process


Lecturer - Iqra Qayyum

IISAT University 1
Content (Book Chapter 4)
• Software Requirement
• Importance and Factors
• Requirement Engineering Phases
1. Requirements Elicitation
2. Requirements Analysis
3. Requirement Specification
4. Requirement Validation
• Software Requirement Specification (SRS) document
• IEEE SRS format discussion

IISAT University 2
Software Requirements
• A requirement is an expression of desired behaviour
• It is the description of desired system functionalities

• A requirement deals with


1. objects or entities
2. the state they can be in
3. functions that are performed to change states or object characteristics

• Requirements focus on the customer needs, not on the solution or


implementation
IISAT University 3
Importance and Factors
• 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

IISAT University 4
Requirement Engineering Phases
• Four phases of Requirement:
1. Elicitation
2. Analysis
3. Specification
4. Validation

IISAT University 5
Requirement Engineering
Process for Capturing Requirements

• Performed by the req. analyst or system analyst


• The final outcome is a Software Requirements Specification (SRS) document

IISAT University 6
1- Requirements Elicitation
• Customers do not always understand what their needs and problems are
• It is important to discuss the requirements with everyone who has a stake in the system
• Come up with agreement on what the requirements are

• Stakeholders involved in elicitation:


 Clients: pay for the software to be developed
 Customers: buy the software after it is developed
 Users: use the system
 Domain experts: familiar with the problem that the software must automate
 Market Researchers: conduct surveys to determine future trends and potential customers
 Lawyers or auditors: familiar with government, safety, or legal requirements
 Software engineers or other technology experts

IISAT University 7
Means of Eliciting Requirements
• Interviewing stake holders
• Reviewing available documentations
• Observing the current system (if one exists)
• Volere requirements process model:

IISAT University 8
2- Requirements Analysis
Requirements quality parameters:
• Atomic
• Uniquely identified
• Complete
• Consistent and unambiguous
• Traceable
• Prioritized
• Testable

IISAT University 9
3- Requirements Specification
• Two Common Ways
• Natural Languages
• Structured Languages
Requirements Specification
1. Natural language Specifications
• It’s a way of writing the requirements in normal plain text
• There is no defined format by default

• Example: “A system shall allow the users to register by entering their


username and password, In order to get an access to the system”.

• Requirements written in natural language are


o Vague
o Ambiguous
o Lack of guidance
Requirements Specification
2. Structured language Specifications
• It’s a way of writing the requirements in more formal and structured form
• It uses standard templates to specify the requirements.
• Structured Languages (mathematical modeling languages):
• Z-notation
• Petri nets
• Temporal Logic etc.
Requirements Specification
3. Graphical Notations (Use Case)
Use cases are a way of describing
interactions between users and a system
using a graphical model and structured
text.
4- Requirements Validation
• Requirements validation is the process of checking that requirements defined for
development, define the system that the customer really wants.
• Similar to requirement analysis
• Requirements analysis: Have we got the right requirements?
• Requirements validation: Have we got the requirements right?
Requirements Validation
• The requirements actually defined the system the customer wants.
• Checks:
 Validity checks
 Consistency checks
 Completeness checks
 Realism checks
 Verifiability
A spiral view of the requirements engineering
process

Chapter 4 Requirements engineering 16


Software Requirement Specification (SRS)
• SRS is a document created by system analyst after the requirements are collected from various
stakeholders.
• SRS defines
 how the intended software will interact with hardware,
 external interfaces,
 speed of operation,
 response time of system,
 portability of software across various platforms,
 maintainability,
 speed of recovery after crashing,
 Security,
 Quality,
 Limitations etc.
• Natural language specification => Structured language specification
Software Requirement Specification (SRS)
• SRS should come up with following features:
• User Requirements are expressed in natural language.
• Technical requirements are expressed in structured language, which is used inside
the organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.
SRS Document -Discussion

• SRS- IEEE Template

You might also like