Characteristics of
Good Requirements
Good Requirements are SMART:
- Specific
- Measurable
- Achievable
- Relevant
- Traceable
Document:
Software Requirement Specification (SRS)
Basic Description
The product of the Requirements Engineering process.
Specifies:
- Services the customer requires
- Constraints under which the system operates and is developed
Types of Requirements
Focus
- User Requirements
- System Requirements
Functionality
- Functional Requirements
- Non-functional Requirements
User Requirements
Summary
Requirements written for customers
Statements are written in natural language, concepts illustrated with simple diagrams
System Requirements
Summary
Written for the development team.
- Structured document, contains detailed descriptions of system functions, services and operational constraints
- Defines what should be implemented
- May be a part of the contract
Functional Requirements
Summary
Includes:
- Statements of services the system should provide
- How the system should react to particular inputs
- How the system should behave in particular situations
- May state what the system should NOT do
Non-Functional Requirements
Summary
- May be difficult to state precisely
- Define system properties, constraints on services or functioning, such as
- timing constraints
- standards
- storage requirements
- May specify development process:
- Process Model/Method
- IDE
- Language
- Often apply to the system as a whole rather than individual features or services
- May be more critical than functional requirements
- Should be verifiable, testable
Who typically reads User Requirements?
- Client Managers
- System End Users
- Client Engineers
- Contractor Managers
- System Architects
Who typically reads
System Requirements?
- System End Users
- Client Engineers
- System Architects
- Software Developers
Completeness and Consistency
of Requirements Specification
The Requirement Specification should be:
- Complete
- Include descriptions of all facilities required
- Consistent
- There should be no conflicts or contradictions in the descriptions of system facilities
Refactoring:
Definition
The process of restructuring existing computer code without changing its external behavior.
Refactoring:
Guidelines
- Perform only one change at a time
- Changes should not add new stuff
- Changes should not break auto-tests
- Only perform a small set of changes as needed, going through them one at a time
Requirements Engineering:
Description
A process that covers all the activities involved in
Discovering, Documenting and Maintaining a set of Requirements.
The process should use systematic and repeatible techniques to ensure the quality of the software requirements.
Requirements Engineering:
Common Activities
Requirements Elicitation
Requirements Analysis
Requirements Validation
Requirements Management
Non-Functional Requirements:
Making them verifiable
Nonfunctional requirements may be very difficult to state precisely.
Imprecise requirements may be difficult to verify.
A Verifiable Nonfunctional Requirement should state some specific measure that can be objectively tested
Non-Functional Requirements:
Possible Metrics
- Speed
- Size
- Ease of Use
- Reliability
- Robustness
- Portability
Writing Requirements:
Guidelines (4)
- Adopt or invent a standard format, use for all requirements
- Use language in a consistent way
- “Shall” for manditory requirements
- “Should” for desirable requirements
- Use text highlighting to identify key parts of requirement
- Include an explanation of why a requirement is necessary
Writing Requirements:
Two Approaches to structuring
Tabular Specification
Structured Specification
Writing Requirements:
Tabular Specification
- Used to supplement natural language
- Useful when defining multiple alternative courses of action
- Different scenarios and settings
Writing Requirements:
Structured Specification
- An approach to writing SRS where requirements are written in a standard way
- The requirements writer must conform to this standard
- Works well for some types of requirements, such as embedded control systems
- Sometimes too rigid for business system requirements
Who typically reads the
Software Requirements Specification (SRS)?
- System Customers
- Managers
- System Engineers
- System Test Engineers
- System Maintenance Engineers
-
Software Engineering Overview14
-
Test Driven Development8
-
Software Engineering Processes24
-
Major Software Development Methods13
-
Agile Development Methods18
-
Verification and Validation9
-
Requirements Specification21
-
Introduction to UML14
-
UML Use Case Diagram10
-
User Interface Design5
-
UML: Class Diagrams9
-
UML: Behavioral Models22
-
Software Architecture12
-
Design and Implementation Phase13
-
Design Patterns18
-
Project Management9
