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

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

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

Requirements process

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

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

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

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

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

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Characteristics of Requirements Correctness Consistency Unambiguity Completeness Feasibility Relevance Testability Traceability

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

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

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

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

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