Requirements Engineering
MBIT - Lecture 1 Introduction to Requirements Engineering
Contents
Course Outline and Evaluation Criteria
Introduction to Requirements Engineering What are Requirements
Stakeholders in Requirements Engineering
Characteristics of Requirements Types of Requirements Importance of Requirements Engineering
Introduction to 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 The entire system development process begins with requirements engineering. What vs. How Software Engineering Process
Vision Why Definition What Development How Maintenance Change
What are Requirements - IEEE
A condition or capability needed by 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.
1.
What are Requirements Jones & Sommerville
1.
2.
The statement of needs by a user that triggers the development of a program or system - Jones 1994
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 1997
Stakeholders in Requirements Engineering
Customer 2. User
1.
1. 2. 3. 4.
Operator Manager Executive General public
Architect 4. Developer 5. QA Engineer 6. Maintenance Engineer
3.
Characteristics of Requirements
1.
2. 3.
Clarity
Precision Completeness
4.
5. 6.
Verifiability
Realistic Traceability
Clarity and Precision
Unambiguous Same meaning for all stakeholders Appropriate representation for different stakeholders
Wireframes, Storyboards for users
DFDs, data flows, ER diagram for developers Component, system diagrams for architects
Completeness
Description of all complexities Cohesive Consistent
No conflicts or contradictions
In practice, it is very difficult to produce a complete, consistent, and cohesive requirement
Realistic and Verifiable
Requirement should be realistic
Computationally Practically Mention success scenarios as well as failure scenarios Test cases covering all logical flows
Verifiability
Verifiable through different states of system
Traceability
Forward tracing
Requirement - UI - Design - Test case
Backward tracing
Test case Design UI Requirement
Types of Requirements
1.
Functional requirements
Domain requirements Customer requirements
User requirements
Business requirements System requirements Product requirements Organizational requirements
2.
Non-functional requirements
External requirements
3.
Direct and Derived requirements
Functional Requirements
Services that system should provide Detailed system requirements Details of the functionality or services
Different types include
Domain requirements Customer requirements
User requirements
Business requirements System requirements
Non-Functional Requirements
Constraints on the system or services Constraints on development process or standards Constraints from users or external sources
Product requirements
Efficiency Performance and Memory Reliability
Portability
Usability Design and architecture
Maintainability
Non-Functional Requirements
Organizational requirements
Processes followed in the organization Delivery Implementation Standards Interoperability Ethical Legislative Safety Privacy
External requirements
Goals & Non-Functional Requirements
Some non-functional requirements are derived from goals and vision behind building the system System Goal Users should be able to learn and adapt to new system within no time Usability, User friendliness System Goal To provide 24/7 service to our customers to maintain their accounts Stability, Sustainability, Maintainability Distinction between functional and non-functional is not always very clear Non-functional requirements should be written in quantitative manner For some goals, quantitative measure is not possible i.e. maintainability
Non-Functional Requirement Measures
Property Speed Measures Transactions / second Requests /second User response time Screen refresh time Memory / RAM consumption Size of page in browser Training time Steps to perform actions Mean time to failure Probability of unavailability Rate of failures
Size Ease of use Reliability
Robustness
Fail-over mechanism Backup Restart time
Platform independence No. of targeted systems
Portability
Conflicts in Non-Functional Requirements
Conflicts in different non-functional requirements are common in complex systems Space vs efficiency Spacecraft system
Minimize weight: use less independent chips Minimize power consumption: use low power chips
Using low power chips means more independent chips
Minimizing weight is more important or minimizing power consumption?
Domain requirements
Derived from the domain of the system May be functional, non-functional, or constraints Understandability
Expressed in terms of language of the domain
Can be difficult to understand by software engineers Domain experts take these development team doesnt as implicit requirements but
Problems with natural language
Lack of clarity Confusion Amalgamation of requirements
Difficult to express complex requirements in terms of natural language
Difficult to express mathematical requirements
Lack of readability
Guidelines for writing requirements
Use standard format Use of diagrams / tables as much as possible Use language in a consistent way
Avoid using computer jargons
Importance of requirements engineering
Boehm (1981) correcting the error after development costs 68 times more than correcting it before Other studies shows it can be as high as 200 times Identifying and defining requirements in proper way is the key to reduce errors Prevention vs Removal of errors
Assignment # 1
1.
2.
Choose a software system of your own liking
Give two examples of each type of requirement that we have studied in context of selected system
3.
4.
Submission Date: Monday, 8th April, 2014
Zero tolerance for Plagiarism
