You are on page 1of 13

Lecture 01 02 Mon, Jan 30 / Feb 06 2012 1800 : 2100 FAST NU, Karachi

Course Outline

Software Requirements Engineering Overview Business Value of Better Requirements Good Practices for Requirements Engineering The Role of Requirements Analyst Documenting Software Requirements Quality Aspect of Requirements Engineering Requirements Management Principles and Practices Improving Requirements Processes Use Cases Risk Management & Software Requirements

Course Material
Software Requirements Karl E. Wiegers Microsoft Press; 2nd Edition; 2003 More About Software Requirements
Thorny Issues and Practical Advice

Karl E. Wiegers Microsoft Press; 2006

Marks Distribution
20% Final Midterm 50% 10% Quiz Presentation / Report

Class Participation
15% 5%

Objective of the Course

To know what Software Requirements Engineering is To understand the need of Requirements Engineering How to understand your customers and how to interact

with them How to develop Software Requirements How to manage Software Requirements How to document Software Requirements How to improve the process of managing the Software Requirements How to define Project Scope How to reduce Risks while managing the Requirements

What is Requirements Engineering

Requirements engineering is primarily a

communication activity not a technical activity Requirements engineering is one of the most challenging aspects of software development It is also the most important aspect, as it lays the foundation for all the subsequent project work

According to Ian Sommerville and Pete Sawyer A specification of what should be implemented They are descriptions of how the system should behave, or of a system property or attribute They may be a constraint on the development process of the system

According to IEEE Standard Glossary of Software

Engineering Terminology
A condition or capability needed by a user to solve a problem or achieve an objective 2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document 3. A documented representation of a condition or capability as in 1 or 2

Levels of Requirements
A project needs to address three levels of

requirements, which come from different sources at different project stages

Business Requirements

Describe why the product is being built and identify the benefits both customers and the business will reap Captured in the form of use cases, describe the tasks or business processes a user will be able to perform with the product

User Requirements

Levels of Requirements
Functional Requirements Describe the specific system behaviors that must be implemented The functional requirements are the traditional shall statements found in a software requirements specification (SRS) System Requirements The term system requirements describes the top level requirements for a product that contains multiple subsystems A system can be all software or it can include both software and hardware subsystems People are a part of a system, too, so certain system functions might be allocated to human beings

Types of Requirements
Business Requirements

Business Rules

Non Functional

Vision and Scope Document

User Requirements

Quality Attributes

Use Case Document

External Interfaces

System Requirements

Functional Requirements Software Requirements Specification



Non Functional Requirements

Business Rules Business rules include corporate policies, government regulations, industry standards (such as accounting practices), and computational algorithms Quality Attributes Quality attributes describe the products characteristics in various dimensions that are important either to users or to developers and maintainers. These characteristics include availability, performance, usability, portability, integrity, efficiency, robustness, and many others Sometimes these characteristics are called quality factors or quality of service requirements

Non Functional Requirements

External Interfaces External interfaces between the system and the outside world constitute another class of nonfunctional requirements Constraints These are restrictions imposed on the choices available to the developer for some legitimate reason Some people consider all requirements to be constraints, but this broad generalization isnt very helpful