Requirements Engineering
Summary
- Definitions?
- Identifying Purpose
- Completeness and Pertinence
- Funcational vs Non-Functional
- User vs System
- Requirement Origins
- Elicitation Process
- Modeling Requirements
- Analyzing Requirements
- Requirements Prioritization
- Requirements Engineering Process
- Software Requirements Specification
Definitions?
Requirements Engineering is the process of establishing the services that the customer requires from the software system, and compares that to the constraints under which the system operates.
Focuses on what, not how
Software is an abstract description of a set of computations that becomes concrete only when we run it on hardware and in the context of some human activity.
Software Intensive Systems := Software + Hardware + Context
We normally take hardware and context for granted, but they need to be explicitly considered.
Software Quality is a function of both the software and its purpose (Fitness for Purpose)
Identifying Purpose
Extremely hard
- Sheer complexity of the purpose
- People don’t know what they want
- Requirements can change
- Many stakeholders can have different requirements
Completeness and Pertinence
It is difficult to get a grasp of the full picture of requirements.
Pertinence pertains to the relevance of the requirements
- This leads to bloat
Funcational vs Non-Functional
Functional Requirements have to do with the function of the system.
- “The elevator shall take people to the floor they select”
Non-Functional Requirements relate to a system’s qualities
- Accuracy
- Security
- Performance
NFR typically don’t have clear criteria
NFR should strive for verifiability
- Not “Elevator should be fast”
- Instead “Elevator should reach the floor in less than 30s”
User vs System
User Requirements are written for customers
- often natural language
- non-technical
System Requirements are written for developers
- detailed func and non-func reqs
- clearly and more rigorously specified
Requirement Origins
Requirements can come from multilple places
- Stakeholders
- Application Domain
- Banks, Medical, etc
- Documentation
Elicitation Process
Domain knowledge is often thinly spread and distributed
Knowledge is often tacit
Observability is often limited
Collected information is often biased
- Consciously or Subconciously
Traditional Techniques
- Background Reading
- Reading random documents
- Good first step
- Hard Data and Samples
- Run experiments/collect data
- Interviews
- Simply talk to people
- Surveys
- Quickly collect info from large number of people
- Meetings
- Good for summarizations of data
- Should have clear intentions/agend
Other Techniques
- Collaborative techniques
- Brainstorming
- Socia approaches
- Ethnographic techniques
- Cognitive techniques
Modeling Requirements
Decide what and how to model
Examples:
- Modeling enterprises
- goals and objectives
- org structure
- task and deps
- agents, roles, intentionality
- Modeling info and behaviors
- information structure
- behavioral view
- scenarios and use cases
- state machine models
- sequence diagrams
- information flow
- time/sequencing requirements
- Modeling system qualities
- Non-Functional Properties
Analyzing Requirements
- Verification
- Completeness and Pertinence
- Validation
- Do the requirements satisfy what the stakeholders want
- Risk Analysis
- Find risks in development
Requirements Prioritization
Limited resources lead to need to prioritize
- Mandatory
- Nice to Have
- Superflous
Requirements Engineering Process
Software Requirements Specification
SRS is a way to communicate requirements to others
Different projects require differen specs
IEEE defines a standard
Simplified standard has three sections:
- Introduction
- User Reqs
- System Reqs
Requirements should be
- simple
- testable
- organized
- numbered (traceable)