Software Requirements

Objectives: l To introduce the concepts of user and system requirements l To describe functional / non-functional requirements & Domain requirements l Problems with Requirements using Natural Language

What is a requirement? It is about WHAT not HOW Requirements are the descriptions of the services provided by a system for the customer and The constraints under which it operates and is developed. It may range from a high level abstract statement to a detailed mathematical (exact/precise) specification It may be as complex as a 500 pages of description This is inevitable as requirements may serve a dual function It may serve as the basis for a bid for a contract or the basis for the contract itself

What is requirements engineering? It is the process of discovering, analyzing, documenting and validating the requirements of the system Each software development process goes through the phase of requirements engineering

Why requirements? What are the advantages of a complete set of documented requirements? Ensures the user (not the developer) drives system functionalities Helps avoiding confusion and arguments Helps minimizing the changes Changes in requirements are expensive. Changing the requirements costs: 3 x as much during the design phase 5-10 x as much during implementation x as much after release [Code Complete]

Why requirements? 2/3 of finished system errors are requirements and design errors A careful requirements process doesn’t mean there will be no changes later Average project experiences about 25% changes in the requirements This accounts for 70-80% rework of the project Important to plan for requirements changes in the case of critical applications

Different levels of abstraction User requirements Usually the first attempt for the description of the requirements Services and constraints of the system In natural language or diagrams Readable by everybody Serve business objectives System requirements Services and constraints of the system in detail Useful for the design and development Precise and cover all cases Structured presentation

Example User requirement: The library system should provide a way to allow a client to borrow a book from the library. System requirement: The library system should provide a withdraw interaction that allows a patron to withdraw a book given the isbn and copy number of the book to be withdrawn. The interaction fails if: The book is already withdrawn, the book is not in the library's collection The client has already withdrawn 5 books The client owes more than Rs5 The book is on hold by someone else…..

Requirements readers

Types of requirements Functional requirements Services the system should provide What the system should do or not in reaction to particular situations Non-functional requirements Constraints on the services or functions offered by the system Examples: Timing constraints, constraints on the development process (CASE, language, development method…), standards etc Domain requirements Come from the application domain of the system and that reflect characteristics of that domain May be functional or non-functional Examples: Medicine, library, physics, chemistry Note: You can have user/system functional/non-functional requirements.

User requirements First attempt to describe functional and non-functional requirements Understandable by the user(natural language NL) Problems Natural Language: Lack of clarity - ambiguous language Requirements confusion - functional, non-functional requirements, design information are not distinguished(illustrious) Requirements amalgamation – several requirements are defined as a single one Incompleteness – requirements may be missing Inconsistency – requirements may contradict themselves

System requirements Elaborate the user requirements to get a precise, detailed and complete version of them Used by designers and developers An important aspect is how to present/write system requirements Natural language is often used! The difference between user and system requirements must not be thought as a detail

Writing system requirements Natural language (informal requirements) Reviled by academics But widely practiced: everybody can read them, finding a better notation is hard Structured natural language Forms/templates are used to bring some rigor (strictness) to natural language presentations Graphical notations Using boxes, arrows… but they mean different things to different people Formal specification Based on logic, state machines… Hard to understand for many people

Functional Requirements(Describe functionality or system services) Depend on the type of software, expected users and the type of system where the software is used Functional user requirements may be high-level statements of what the system should do BUT functional system requirements should describe the system services in detail

Non-functional requirements(Define system properties and constraints ) They can be categorized into: Product requirements Product behavior Ex: Timing, performance, memory, reliability, portability, usability Organizational requirements Policies and procedures in the customer’s and developer’s organizations Example: Process requirements, implementation requirements, delivery requirements External requirements Factors externals to the system and the development process Example: Interoperability, legislation, ethics Non-functional requirements may be more critical than functional requirements. (The system may be useless…)

Non-functional requirements It is important to be able to test/verify/check non- functional requirements

Domain requirements Derived from the application domain and describe system characteristics and features that reflect the domain If domain requirements are not satisfied, the system may be unworkable

Problems with NL specification Ambiguity The readers and writers of the requirement must interpret the same words in the same way. NL is naturally vague so this is very difficult Over-flexibility The same thing may be said in a number of different ways in the specification Lack of modularisation NL structures are inadequate to structure system requirements

Example: If sales for current month are below target sales, then report is to be printed unless difference between target sales and actual sales is less than half of difference between target sales and actual sales in previous month, or if difference between target sales and actual sales for the current month is less than 5%. Problems: Difficult to read Ambiguity: sales and actual sales, 5% of what? Incomplete: what if sales are above target sales?

THANK YOU !