CMSC 345 Fall 2000 Requirements Overview

Work with customers to elicit requirements by asking questions, demonstrating similar systems, developing prototypes, etc. Capture written requirements in document Verify to ensure complete, correct and consistent Validate to ensure requirements describe what customer intends for final product

Participants Contract monitors – milestones and schedules Customers and users – meet needs Business managers – business consequences of building and using Designers – develop solution to be implemented as software-based system Testers – test suites ensure system satisfies each requirement

Requirements Categories Absolutely must be met Highly desirable but not necessary Possible but could be eliminated

Requirements Focus Requirements deal with objects or entities, the states they can be in and the functions that are performed to change state Requirements are specific descriptions of functions or characteristics Requirements define system objects, limit them, or define relationships among them Requirements DO NOT specify how the system is to be implemented

Functional Requirements Describe interaction between system and its environment Acceptable states, or sets of conditions, for system to be in What should cause system or entities in system to transition from one state to another, or to perform an activity Describe system activities and state of system before and after each activity Independent of implementation

Nonfunctional Requirements Restrictions on system that (may) limit implementation choices Constraints (may) narrow selection of language, platform, implementation techniques or tools Actual selection made at design time, after requirements specified

Types of Requirements (1) Physical Environment Where will equipment be located Any environmental restrictions – temperature, humidity, magnetic interference, etc. Interfaces Input coming from one or more other systems Output going to one or more other systems Prescribed data formats Prescribed data media

Types of Requirements (2) Users and Human Factors Who are the users Skill levels and training for each type How easy to understand and use How difficult to misuse Functionality What will system do, when, and in which modes How/when changed or enhanced Execution speed, response time, throughput, etc.

Types of Requirements (3) Documentation How much Who’s the audience Format (on-line, printed) Data Input and output formats How often sent/received Accuracy, degree of precision for calculations How much data flow through system Data retention period

Types of Requirements (4) Resources Materials, personnel, etc. Physical space, power, heating, air conditioning Developer skills, development timetable Hardware and software costs Security System and information access control Isolate one user’s data from others Isolate user’s programs from others Backup frequency and storage Precautions against fire, water damage, theft

Types of Requirements (5) Quality Assurance Reliability, availability, maintainability, security, other quality attributes How will characteristics be demonstrated Prescribed mean time between failures Maximum time for restart after failure How will design changes be incorporated Will maintenance focus on correcting vs. improving Measures for resource usage and response time How easy to move among locations or port among computers

Requirements Verification Correct – stated without error Consistent – no conflicts or ambiguities Complete – all possible states, state changes, inputs, outputs, products and constraints described External – all ties to environment covered Internal – no undefined references

Requirements Verification Realistic – can this really be done Needed (by customer) – avoid unnecessary restrictions or irrelevant functions Verifiable – must be able to demonstrate requirements have been met Traceable – each system function must be mandated by specific requirement(s)

Exercise Developers work together with customers and users to define requirements and specify what the proposed system will do. If, once it is built, the system works according to specification but harms someone physically or financially, who is responsible?

Exercise Sometimes a customer requests a requirement that you know is impossible to implement. Should you agree to put in the requirement in the specification document anyway, thinking you might come up with a novel way of meeting it or thinking you will ask the requirement be dropped later? Discuss the ethical implications of promising what you know you cannot deliver.