all important topics and well described

1. Software Requirements Engineering
Dr. Faheem Ahmed
Assistant Professor, FET

2. Course Benefits
• Improve the quality of your project’s requirements early
in the development cycle, which reduces rework and
improves productivity.
• Meet schedule objectives by controlling scope creep and
requirements changes.
• Achieve higher customer satisfaction.
• Reduce maintenance and support costs.

3. Course Overview
1. Software Requirements: What, why,who,when and how
2. Requirements Development
3. Requirements for Specific Project Classes
4. Requirements Management
5. Implementing Requirements Engineering

4. Books
Software Requirements (3rd Edition)
• Karl E.Wiegers
• Joy Beatty
Managing Software Requirements: A Use Case
Approach (Second Edition)
• Dean Leffingwell
• DonWidrig
The Guide to the Business Analysis Body of
Knowledge (Version 3.0)
• International Institute of Business Analysis

6. PART 1
Software Requirements:What, Why,How,When and Who

7. The Essential Software Requirement
Chapter 1

8. Factors that contribute to Project
Failure?
1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
4. Lack of Executive Support
5. Technology Incompetence
6. Lack of Resources
7. Unrealistic Expectations
8. UnclearObjectives
9. Unrealistic Schedule
10. NewTechnology

9. Factors that contribute to Project
Failure?
1. Lack of User Input
2. Incomplete Requirements & Specifications
3. Changing Requirements & Specifications
4. Lack of Executive Support
5. Technology Incompetence
6. Lack of Resources
7. Unrealistic Expectations
8. UnclearObjectives
9. Unrealistic Schedule
10. NewTechnology

10. Size is Important!

11. The High Cost of Requirement
Errors

12. 1.1 Software Requirements Defined
• Consultant Brian Lawrence suggests that a requirement is
"anything that drives design choices" (Lawrence 1997).
• The IEEE Standard Glossary of Software Engineering
Terminology (1990) defines a requirement as
• A condition or capability needed by a user/stakeholder to solve a
problem or achieve an objective.
• 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.
• A documented representation of a condition or capability as in 1 or
2.

13. 1.1 Software Requirements Defined
• Requirements are 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.
(Sommerville and Sawyer 1997)
Don't assume that all your project stakeholders share a
common notion of what requirements are. Establish
definitions up front so that you're all talking about the same
things.

14. 1.1 Software Requirements Defined
• Requirements are specific descriptions of the client’s
needs

15. Requirements are Not :
• Requirements specifications do not include design or implementation
details (other than known constraints), project planning information, or
testing information (Leffingwell andWidrig 2000).
• Requirements are independent of design, showing “what” the system
should do, rather than “how” it should be done.

16. Levels of Requirements
• Business Requirements
• User Requirements
• Functional Requirements
• Non-Functional Requirements
In addition, every system has an assortment of
nonfunctional requirements

17. Levels of Requirements
• Business Requirements
A high-level business objective of the organization that
builds a product or of a customer who procures it.
• come from the funding sponsor for a project, the acquiring
customer, the manager of the actual users, the marketing
department, or a product visionary.
• describe why the organization is implementing the system—the
objectives the organization hopes to achieve.
• recorded in aVision and Scope document, Project Charter or a
Market Requirements document.

18. Levels of Requirements
• User Requirements
A goal or task that specific classes of users must be able to
perform with a system, or a desired product attribute.
• describe user goals or tasks that the users must be able to
perform with the product.
• describe what the user will be able to do with the system
• valuable ways to represent user requirements include use cases,
scenario descriptions and event response tables.

19. Levels of Requirements
• Functional Requirements
A description of a behavior that a system will exhibit under
specific conditions.
• specify the software functionality that the developers must build
into the product to enable users to accomplish their tasks,
thereby satisfying the business requirements.
• also called behavioural requirements
• recorded in a Software Requirements Specification (SRS).

20. Levels of Requirements
• System Requirements
A top-level requirement for a product that contains multiple
subsystems, which could be all software or software and
hardware
• Describes the top level requirements for a product that contains
multiple subsystems – that is, a system
• A system can be all software or it can include both software and
hardware subsystems

21. Levels of Requirements
• Business Rules
A policy, guideline, standard, or regulation that defines or
constrains some aspect of the business. Not a software
requirement in itself, but the origin of several types of software
requirements.
• Include corporate policies, government regulations, industry
standards, accounting practices and computational algorithms
• Business Rules are not themselves software requirements
because they exist outside the boundaries of any specific
software system

22. Levels of Requirements
• Quality Attributes
• They augment the description of the product’s functionality by
describing the product’s characteristics in various dimensions that
are important to users such as portability, integrity, efficiency and
robustness.
• Constraints
• Impose restrictions on the choices available to the developer for
design and construction of the product
• External interface requirement
• A description of a connection between a software system and a user,
another software system, or a hardware device.

23. Levels of Requirements
• Product Features
• One or more logically related system capabilities that provide
value to a user and are described by a set of functional
requirements.
• A feature can encompass multiple use cases and each use case
requires that multiple functional requirements be implemented
to allow the user to performs the task

24. Levels of Requirements
• Software Requirements Specifications Document
• Functional requirements are documented in SRS document
which describes as fully as necessary the expected behaviour of
the software system.
• Development,Testing, Quality Assurance, Project Management
and related project functions
• Non functional requirements- performance goals and
descriptions of quality attributes.They describe external
interfaces between system and the outside world and design and
implementation constraints.

25. Levels of Requirements

26. Requirements Development &
Management

27. Requirements Development &
Management
• Requirements Development
• Identifying the product's expected user classes
• Eliciting needs from individuals who represent each user class
• Understanding user tasks and goals and the business objectives
with which those tasks align
• Analyzing the information received from users to distinguish
their task goals from functional requirements, non-functional
requirements, business rules, suggested solutions, and
extraneous information

28. Requirements Development &
Management
• Allocating portions of the top-level requirements to software
components defined in the system architecture
• Understanding the relative importance of quality attributes
• Negotiating implementation priorities
• Translating the collected user needs into written requirements
specifications and models
• Reviewing the documented requirements to ensure a common
understanding of the users' stated requirements and to correct
any problems before the development group accepts them

29. Requirements Development &
Management
• Requirements Management
• Defining the requirements baseline (a snapshot in time
representing the currently agreed-upon body of requirements
for a specific release)
• Reviewing proposed requirements changes and evaluating the
likely impact of each change before approving it
• Incorporating approved requirements changes into the project in
a controlled way

30. Requirements Development &
Management
• Keeping project plans current with the requirements
• Negotiating new commitments based on the estimated impact
of requirements changes
• Tracing individual requirements to their corresponding designs,
source code, and test cases
• Tracking requirements status and change activity throughout
the project

31. Requirements Development &
Management

32. Every project has Requirements
The hardest single part of building a software system is
deciding precisely what to build.
(Frederick Brooks: No Silver Bullet: Essence and
Accidents of Software Engineering)

33. When Bad Requirements Happen to
Nice People

34. When Bad Requirements Happen to
Nice People
• Insufficient User Involvement
• Creeping User Requirements
• Ambiguous Requirements
• Gold Plating
• Minimal Specification
• Overlooked User Classes
• Inaccurate Planning

35. Benefits from a High-Quality
Requirements Process
• Fewer requirements defects
• Reduced development rework
• Fewer unnecessary features
• Lower enhancement costs
• Faster development

36. Benefits from a High-Quality
Requirements Process
• Fewer miscommunications
• Reduced scope creep
• Reduced project chaos
• More accurate system-testing estimates
• Higher customer and team member satisfaction

37. Requirement Statement
Characteristics
• Complete
• Each requirement must fully describe the functionality to be delivered.
• Correct
• Each requirement must accurately describe the functionality to be built.
• Feasible
• It must be possible to implement each requirement within the known
capabilities and limitations of the system and its operating environment
• Necessary
• Each requirement should document a capability that the customers really
need or one that's required for conformance to an external system
requirement or a standard.

38. Requirement Statement
Characteristics
• Prioritized
• Assign an implementation priority to each functional requirement,
feature, or use case to indicate how essential it is to a particular
product release.
• Unambiguous
• All readers of a requirement statement should arrive at a single,
consistent interpretation of it, but natural language is highly prone
to ambiguity.
• Verifiable
• See whether you can devise a few tests or use other verification
approaches, such as inspection or demonstration, to determine
whether the product properly implements each requirement.

39. Requirements Specification
Characteristics
• Complete
• No requirements or necessary information should be absent.
• Consistent
• Consistent requirements don't conflict with other requirements of
the same type or with higher-level business, system, or user
requirements..
• Modifiable
• You must be able to revise the SRS when necessary and to maintain
a history of changes made to each requirement.
• Traceable
• A traceable requirement can be linked backward to its origin and
forward to the design elements and source code that implement it
and to the test cases that verify the implementation as correct.