1. Requirements/Systems analyst
Person performing the tasks of determining the requirements for a proposed software system
(problem analysis) breaking down what the customer wants into discrete requirements

2. Requirements Goal of requirements phase What is requirements?
understand the customer’s problems and needs
What is requirements?
An expression of desired behaviour
Deals with objects/entities, states they can be in, and functions that are performed to change state or object characteristics
Designates what behaviour the customer wants without saying how the behaviour will be realised

3. Specification and Design
Specification makes decisions on which requirements will be fulfilled by our software system
As opposed to those that are addressed by special purpose hardware devices, by other software systems or by human operator or users
In design, a plan is devised as to how the specified behaviour will be implemented

4. Requirements process

5. Requirements Process - Elicitation
Collecting the user requirements by:
Asking questions
Examining current behaviour
Demonstrating similar systems

6. Requirements Process - Analysis
Understanding and modelling the desired behaviour
Modelling or prototyping the requirements helps us to better understand the required behaviour
Also raises additional questions about what the customer wants to happen in certain situations
May expose problems or omissions in our models that cause us to revisit the customer and revise our models

7. Requirements Process - Specification
Documenting the behaviour of the proposed software system
Requirements are well understood
Then it is decided which parts of the required behaviour will be implemented in this software system

8. Requirements Process - Validation
Checking that our specification matches the user’s requirements
Matches developer’s specifications with user’s expectations of the final product
May expose problems or omissions in our specifications that cause us to revisit the customer and revise our specifications

9. Requirements Process – Software Requirements Specifications
Eventual outcome of the requirements process
Is used to communicate to the other software developers (designers, testers, maintainers) how the final product ought to behave

10. Requirements Elicitation
Critical part of the process
Must use a variety of the techniques to determine what the users and the customers really want
Discussion with everyone who has a stake in the system and coalescing these different views into a coherent set of requirements

11. Stakeholders in Requirements Elicitation Process
Clients
Customer
Users
Domain Experts
Market Researchers
Lawyers or auditors
Software engineers or other technology experts

12. Stakeholders in Requirements Elicitation Process
Clients
Pay for software to be developed
Ultimate stakeholders as they have final say on what product does
Customers
Buy software after it is developed
Users
Experts on how current system works (most useful features, features that need improvement)
Need to understand particular needs of special groups (differently-abled individuals, persons unfamiliar with computers, expert users)

13. Stakeholders in Requirements Elicitation Process
Domain experts
Familiar with the problem that software must automate (financial expert for a financial package, meteorologist for software to model weather)
Also know about kinds of environment to which product will be exposed
Market Researchers
Conduct surveys to determine future trends and potential customers’ needs

14. Stakeholders in Requirements Elicitation Process
Lawyers/auditors
Familiar with government, safety or legal requirements (tax expert ensures payroll package adheres to tax law, experts on standards which are relevant to product’s functions)
Software Engineers/other technology experts
Ensures that the product is technically and economically feasible
Educate customer about innovative technology, recommend new functionality taking advantage of these technologies, and can estimate cost and development time

15. Techniques for Eliciting Requirements
Interviewing stakeholders
Reviewing available documentation
Observing current system (if one exists)
Apprenticing with users
Interviewing users/stakeholders in groups
Using Domain-specific strategies
Brainstorming

16. Techniques for Eliciting Requirements
Interviewing stakeholders
To capture the many views of the system and how it should work
Reviewing available documentation
Documented procedures of manual tasks
Specifications or user manuals of automated system
Observing current system (if one exists)
Gather objective information about how users perform their tasks
Better understand the system that the developers are about to automate or change

17. Techniques for Eliciting Requirements
Apprenticing with users
Learn more about users’ tasks in more detail as the user performs them
Interviewing users/stakeholders in groups
So that they will be inspired by one another’s ideas
Using domain-specific strategies
To ensure that stakeholders consider specific types of requirements that are relevant to their particular situations
Brainstorming with current and potential users about how to improve the proposed product

18. Types of Requirements – Functional Requirements
Describes a required behaviour in terms of required activities
e.g. reactions to inputs, states of each entity before and after an activity occurs
Defined boundaries of a solution space for our problem
Solution space is the set of possible ways that software can be designed to implement the requirements

19. Types of Requirements – Quality / Non-Functional Requirements
Describes some quality characteristic that the software solution must posses
e.g. fast response time, ease of use, high reliability and low maintenance costs
Design criteria that can be optimised and used to choose among alternative implementations of functional requirements

20. Make Requirements Testable
Make requirements testable so the conclusion of whether or not a proposed solution meets the requirement, must not vary according to who is doing the evaluation
Fit criteria
Objective standards for judging whether a proposed solution satisfies the requirements

21. Constraints on Requirements – Design Constraints
Design decision that has already been made and that restricts the set of solutions to our problem
e.g. choice of platform or interface components
Process constraint
Restriction on the techniques or resources that can be used to build the system
e.g. customer may insist that we use agile methods, so that they can use early versions of the system while we continue to add features

22. Requirements Problem - Conflict
May encounter conflicting ideas of what requirements ought to be, when eliciting from stakeholders
Possible solutions are
Ask customer to prioritise requirements
Negotiation

23. Conflict Solutions – Customer prioritises requirements
Helps customer reflect on which of requested services and features are most essential
Loose prioritisation scheme separates requirements into 3 categories
Essential  Requirements that absolutely must be met
Desirable  Requirements that are highly desirable but not necessary
Optional  Requirements that are possible but could be eliminated

24. Conflict Solutions – Negotiation
Requires skills, patience and experience in finding mutually acceptable solutions
With effective negotiation, stakeholders will
understand and appreciate each other’s fundamental needs and
strive for a resolution that satisfies everyone

25. Different Purposes of Requirements
Requirements analysts and their clients
To explain their understanding of how the system would behave
Designers
As constraints on what would be considered an acceptable solution
Test team
To derive a suite of acceptance tests
Maintenance team
To help ensure that the system enhancements do not interfere with the system’s original intent

26. Requirements Documents
Requirements Definition
Aimed at a business audience, such as clients, customers and users
Complete listing of everything customer wants to achieve
Written entirely in terms of environment, describing how the environment will be affected by the proposed system
Requirements Document
Aimed at a technical audience, such as designers, testers and project managers
Restates requirements as a specification of how proposed system will behave
Written entirely in terms of environment, except that refers solely to environmental entities that are accessible to the system via its interface

27. Characteristics of Requirements
Correctness
Consistency
Unambiguity
Completeness
Feasibility
Relevance
Testability
Traceability

28. Characteristics of Requirements
Correctness
Developer and customer should ensure conformity to our understanding of the requirements
Consistency
No conflicting requirements, as inconsistent requirements cannot be satisfied simultaneously
Unambiguity
Multiple readers of requirements should have different but valid interpretations

29. Characteristics of Requirements
Completeness
Set of requirements is defined as complete if it specifies required behaviour and output for all possible inputs in all possible states under all possible constraints
Externally complete  if all states, state changes, inputs, products, and constraints are described by some requirement
Internally complete  if there are no undefined terms among the requirements

30. Characteristics of Requirements
Feasibility
Existence of a solution to customer’s need
Relevance
Indirectly related to customer’s need or may restrict developers unnecessarily
Testability
Existence acceptance tests that would clearly demonstrate whether the eventual product meets the requirements
Traceability
Organisation of requirements for easy reference
There should be correspondence between every entry in the requirement definition and requirements specification, and vice versa

31. Purpose of characteristics
Help in making the decision when we have collected enough information
Also when we need to learn more about what a particular requirement means

32. Purpose of characteristics
The degree to which we want to satisfy these characteristics will affect:
Type of information that we gather during requirements elicitation, and how comprehensive we want to be
Specification language we choose to express the requirements and the validation and verification checks that we eventually perform to assess the requirements