Requirements Engineering Lecture 1 Introduction to Requirements Engineering

Requirements Engineering Lecture 1 Introduction to Requirements Engineering Jerzy. Nawrocki@put. poznan. pl www. cs. put. poznan. pl/jnawrocki/mse/require/ J. Nawrocki, Requirements Eng. , Lecture 1 Copyright, 2000 © Jerzy R. Nawrocki

Plan of the lecture Introduction • What are requirements? • System vs. software requirements • CMM level 2 Requirements management • Goals & commitment • Abilities • Activities • Measurement • Verification Plan of the course J. Nawrocki, Requirements Eng. ,

Introduction The Little Prince You can imagine my surprise at sunrise when an odd little voice woke me up. It said: ‘Please. . . draw me a sheep. ’ (. . ) So I drew. He looked at it carefully and said: ‘No. That one is already very sick. Draw me another one. ’ J. Nawrocki, Requirements Eng. ,

Introduction The Little Prince And I drew. My little friend said gently and indulgently: ‘Don’t you see that is not a sheep, it is a ram. It has horns. . . ’ J. Nawrocki, Requirements Eng. ,

Introduction The Little Prince Once again, I made another drawing. But it was rejected too, like the previous ones. ‘This one is too old. I want a sheep that will live for a long time. ’ J. Nawrocki, Requirements Eng. ,

Introduction The Little Prince My patience had run out by then (. . ), so I scribbled this drawing. And I explained: ‘That is only the box. The sheep you asked for is inside. ’ But I was very surprised to see the face of my young judge lighting up: ‘That is exactly the way I wanted it. ’ J. Nawrocki, Requirements Eng. ,

Introduction What are requirements? How the system should behave (product) or how it should be built (process): • ‘The word processor must include a spell checking facility. ’ • ‘Personal information must never be available without authorisation. ’ • ‘Temperature must be checked every 2 seconds. ’ • ‘The system must be coded in Java. ’ J. Nawrocki, Requirements Eng. ,

Introduction System vs. software requirements A system requirement: Spelling must be checked. A software requirement: Spelling of all HTML files must be checked automatically. J. Nawrocki, Requirements Eng. ,

Introduction System requirements J. Nawrocki, Requirements Eng. , Users Software Hardware

Introduction System requirements Skills & resources Software requirements Hardware requirements J. Nawrocki, Requirements Eng. ,

Introduction CMM Level 2 - Repeatable CMM J. Nawrocki, Requirements Eng. , • Requirements management • Software configuration management • Software quality assurance • Software project planning and oversight • Software project tracking • Software subcontract management

Introduction CMM Level 2 - Repeatable J. Nawrocki, Requirements Eng. , Project tracking Quality assurance Project planning Configuration management Requirements management

Plan of the lecture Introduction • What are requirements? • System vs. software requirements • CMM level 2 Requirements management • Goals & commitment • Abilities • Activities • Measurement • Verification Plan of the course J. Nawrocki, Requirements Eng. ,

Requirements management Goal 1 Software requirements are controlled to establish a baseline for software engineering and management use. J. Nawrocki, Requirements Eng. ,

Requirements management Goal 2 Software plans, products and activities are kept consistent with software requirements. J. Nawrocki, Requirements Eng. ,

Requirements management Organisational policy for requirements J. Nawrocki, Requirements Eng. ,

Requirements management Ability 1 Why me? For each project responsibility is established for analysing the system requirements and allocating them to: • hardware, • software, and • other system components. J. Nawrocki, Requirements Eng. ,

Requirements management Ability 1 This responsibility covers: • managing & documenting the system requirements, • managing & documenting their allocation, • effecting changes to the system requirements & their allocation. J. Nawrocki, Requirements Eng. ,

Requirements management Ability 2 The allocated requirements are documented. The allocated requirements include: e b t s u M y d a re ay! tod J. Nawrocki, Requirements Eng. , • non-technical requirements, • the acceptance criteria.

Requirements management Ability 3 Adequate resources and funding are provided for managing the allocated requirements. • Experienced individuals in SE and in application domain. • Tools are made available. J. Nawrocki, Requirements Eng. ,

Requirements management Ability 4 Software engineers are trained to perform their requirements management activities. Examples: • methods, standards, procedures • the application domain J. Nawrocki, Requirements Eng. ,

Requirements management Activity 1 The software engineers review the allocated requirements before they are incorporated into the software project. Identification of • incomplete requirements, • missing requirements, • unfeasible requirements, • unclear requirements, • not testable requirements, • inconsistent requirements. J. Nawrocki, Requirements Eng. ,

Requirements management Activity 1 “Problematic” requirements are discussed and negotiated with the system requirements group. Commitments are negotiated with the affected groups: • Design group J. Nawrocki, Requirements Eng. , • Effort estimating team • System engineers • System testers • Contract management • Documentation support, . . .

Requirements management Activity 2 Work products Plans Activities Requirements The software engineers use the allocated requirements as the basis for • software plans, • work products, and • activities. J. Nawrocki, Requirements Eng. ,

Requirements management Activity 2 Work products Plans Activities Requirements The allocated requirements are managed & controlled (version control & change control), The system requirements are basis for developing the software requirements. J. Nawrocki, Requirements Eng. ,

Requirements management Activity 3 Changes to the allocated requirements are reviewed and incorporated into the software project. Changes to external commitments are reviewed e s with senior management. n o p s e s R 1 < s e Changes to local tim 0. 1 commitments are reviewed with the affected groups. J. Nawrocki, Requirements Eng. ,

Requirements management Activity 3 e s n o p s Re < 1 s e 1 s m i t 0. J. Nawrocki, Requirements Eng. , Proposed changes are • identified, • evaluated, • assessed for risk, • documented, • planned, • communicated, • tracked to completion.

Requirements management Measurements are made and used to determine the status of the activities for managing the allocated requirements. Examples: • Cumulative number of changes proposed, open, approved, incorporated into the system baseline. • Status of each requirement. J. Nawrocki, Requirements Eng. ,

Requirements management Verification 1 The activities for managing the allocated requirements are reviewed with senior management on a periodic basis. I have a meeting! If the period is lengthy, then a mechanism for exception reporting is necessary. J. Nawrocki, Requirements Eng. ,

Requirements management Verification 2 The activities for managing the allocated requirements are reviewed with the project manager on both a periodic and event driven basis. J. Nawrocki, Requirements Eng. ,

Requirements management Verification 3 The software quality assurance group reviews and / or audits the activities and work products for managing the allocated requirements and reports the results. J. Nawrocki, Requirements Eng. ,

Requirements management Verification 3 At a minimum those reviews/audits verify that: The requirements are reviewed and problems are resolved before SW engineers commit to them. The plans, products, and activities are appropriately revised when the allocated requirements change. J. Nawrocki, Requirements Eng. ,

Requirements management Verification 3 At a minimum those reviews/audits verify that: Changes to commitments resulting from changes to the allocated requirements are negotiated with the affected groups. J. Nawrocki, Requirements Eng. ,

Plan of the lecture Introduction • What are requirements? • System vs. software requirements • CMM level 2 Requirements management • Goals & commitment • Abilities • Activities • Measurement • Verification Plan of the course J. Nawrocki, Requirements Eng. ,

Plan of the course Part 1 - The document • Introduction • Software Requirements Specification • Use scenarios • Requirements modelling in UML J. Nawrocki, Requirements Eng. ,

Plan of the course Part 2 - The process • Communication issues • Requirements Elicitation • FAST Technology • Change Management • Reviews and Inspections J. Nawrocki, Requirements Eng. ,

Plan of the course Part 3 - Advanced issues • Risk management • Function points • Web-based requirements engineering • e. Xtreme Programming J. Nawrocki, Requirements Eng. ,

Summary Requirements: how the system should behave System requirements software requirements CMM level 2 Requirements management: • documentation • reviews & quality assurance • change management J. Nawrocki, Requirements Eng. ,

Further readings • CMM Practices (version 1. 1), CMU/SEI-93 -TR-25. • I. Sommerville, P. Sawyer, Requirements Engineering, John Wiley & Sons, Chichester, 1997. J. Nawrocki, Requirements Eng. ,

Homework • Write organisational policy for managing software requirements in your company or project team. J. Nawrocki, Requirements Eng. ,

Quality assessment 1. What is your general impression? (1 - 6) 2. Was it too slow or too fast? 3. What important did you learn during the lecture? 4. What to improve and how? J. Nawrocki, Requirements Eng. ,