Requirements Engineering (WK3&4) Flashcards
What is a requirement and why do we care?
A requirement tells us what the system needs to do (not at an implementation level)
Requirements engineering is the process of establish what a customer required from a system and the constraints under which it is operated/developed.
User and system requirements
User requirements: written for customers, statements in natural language/diagrams describing services provided and operational constraints
System requirements: What is needed to run. Defines what should be implemented
System stakeholders
Any person/organisation who is affected by the system or who has a vested interest in it. Some stakeholder types: end users, system managers, system owners, etc. Software engineers aren’t stakeholder in their own system for the purposes of this course.
What are the four requirements engineering processes?
- requirements elicitation
- requirements analysis
- requirements validation
- requirements management
Completeness and consistency
Requirements should be complete and consistent
Completeness: they should include descriptions of all facilities required
Consistency: there should be no conflicts or contradictions in the descriptions
Domain Requirements
Constraints on the system from the domain of operation (areas where the reqs reside)
Ex: database, User interface, distributed system
These can be formed from functional ornon-functional requirements, and canconstrain the already defined system requirements.These are generally more technically-based,and ensure that the system will actually work onceimplemented.
Functional Requirements
Describe functionality or system services.
Examples:
- When a grade is released, a notification shall be given to the student on their course dashboard
- All students can log in to the course system using their unique student ID number
Non-functional requirements
Define system properties and constraints (eg. reliability, response time, storage req, etc). May be more critical than functional requirements, and a single non-functional requirement may generate multiple functional requirements.
Examples:
-The online course system shall be available to all users 24/7 and non-planned downtime shall not exceed ten seconds in any one day
-Video-based course materials shall be available tostudents in at least 480p quality
Classifications of non-functional requirements
Product requirements: specify how the product must behave
Organisational requirements: req stemming from organisational policies/procedures (such as standard processes)
External requirements: arise from external factors such as legislative requirements, regulatory/ethical, accounting, etc.
Metrics for specifying non-functional requirements
Examples:
- Speed (transactions/second, response time, refresh time)
- Size (Mbytes, number of ROM chips)
- ease of use (training time, number of help frames)
- reliability (mean time to failure, probability of unavailability, rate of failure occurrence)
- robustness (time to restart after failure, probability of data corruption on failure)
Methods for eliciting requirements
Individual interviews: private and in-depth, but, time-consuming and not good for domain requirements.
Focus groups: peer interactions, uncover a lot in a short time, but, may be dominant speakers, peer pressure, and its dependent on the moderator.
Scenarios: using examples. Can criticise how they might interact with the software system.
Ethnographic studies: observational study of behaviours. Effective for understanding existing processes.
What are some different ways of specifying requirements?
- natural language
- structured natural language (using form or template)
- design description languages
- graphical notations (UML use case and sequence diagrams)
- mathematical specifications
Natural Language for requirements specification
Guidelines for writing requirements: invent a standard format, use text highlighting, avoid the use of jargon, include an explanation of why its necessary.
Problems with natural language: lack of clarity, requirements confusion (functional and non-functional), requirements amalgamation (several may be represented together)
Structured requirements specifications
Example structure:
- Definition of function or entity
- description of inputs and outputs
- information needed for computation
- description of action to be taken
- pre and post conditions (if applicable)
- side effects (if any)
Use cases
High-level graphical model to visualise the system design with actors. See mentcare example.
UML sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.
What is requirements validation?
Demonstrating the the requirements defining the system are actually what the customer wants. Requirement error costs are HIGH.
Two methods: requirements reviews, prototyping
Requirements Verification
Can the requirements be checked?
All functional and non-functional requirements should be verifiable (measurable!)
Requirements completeness and realism
Completeness: are all functions required but the customer included
Realism: can the requirements actually be implemented given available budget and technology
Prototyping (Change anticipation)
A version or part of the system is developed quickly to check the customers requirements and feasibility - supports change anticipation.
Examples: paper model, UI mockup (proof of concept)
Prototyping may involve leaving out functionality - focus on functional rather than non-functional requirements
Incremental development (change tolerance)
System increments delivered to customer for comment/experimentation. This supports change avoidance and change tolerance.
Requirements are prioritised in order of importance.
- Focus on incremental value addition (camp site example)
