Introduction to Requirements Engineering Copyright, 2000 © Jerzy R. Nawrocki Requirements Engineering Lecture 1 Requirements Engineering Lecture 1

J. Nawrocki, Requirements Eng., Lecture 1 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., Lecture 1 IntroductionIntroduction 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. The Little Prince He looked at it carefully and said: ‘No. That one is already very sick. Draw me another one.’

J. Nawrocki, Requirements Eng., Lecture 1 IntroductionIntroduction 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., Lecture 1 IntroductionIntroduction 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., Lecture 1 IntroductionIntroduction 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., Lecture 1 IntroductionIntroduction 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.’ What are requirements?

J. Nawrocki, Requirements Eng., Lecture 1 IntroductionIntroduction 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., Lecture 1 IntroductionIntroduction System requirements Hardware Software Users System

J. Nawrocki, Requirements Eng., Lecture 1 IntroductionIntroduction System requirements Hardware requirements Software requirements Skills & resources System requirements

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

J. Nawrocki, Requirements Eng., Lecture 1 Projecttracking Projectplanning Configuration management Quality assurance IntroductionIntroduction CMM Level 2 - Repeatable Requirements management

J. Nawrocki, Requirements Eng., Lecture 1 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., Lecture 1 Requirements management Goal 1 Software requirements are controlled to establish a baseline for software engineering and management use.

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

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

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

J. Nawrocki, Requirements Eng., Lecture 1 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., Lecture 1 Requirements management Ability 2 The allocated requirements are documented. The allocated requirements include: non-technical requirements, technical requirements, the acceptance criteria. Must be ready today!

J. Nawrocki, Requirements Eng., Lecture 1 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., Lecture 1 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., Lecture 1 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., Lecture 1 Requirements management Activity 1 “Problematic” requirements are discussed and negotiated with the system requirements group. Commitments are negotiated with the affected groups: Design group Effort estimating team System engineers System testers Contract management Documentation support,...

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

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

J. Nawrocki, Requirements Eng., Lecture 1 Requirements management Activity 3 Changes to the allocated requirements are reviewed and incorporated into the software project. Response time < 1 s 0.1 s Changes to external commitments are reviewed with senior management. Changes to local commitments are reviewed with the affected groups.

J. Nawrocki, Requirements Eng., Lecture 1 Requirements management Activity 3 Response time < 1 s 0.1 s Proposed changes are identified, evaluated, assessed for risk, documented, planned, communicated, tracked to completion.

J. Nawrocki, Requirements Eng., Lecture 1 Requirements management Measurement 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., Lecture 1 Requirements management Verification 1 The activities for managing the allocated requirements are reviewed with senior management on a periodic basis. If the period is lengthy, then a mechanism for exception reporting is necessary. I have a meeting!

J. Nawrocki, Requirements Eng., Lecture 1 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., Lecture 1 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., Lecture 1 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., Lecture 1 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., Lecture 1 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., Lecture 1 Plan of the course Introduction Software Requirements Specification Use scenarios Requirements modelling in UML Part 1 - The document

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

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

J. Nawrocki, Requirements Eng., Lecture 1 SummarySummary 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., Lecture 1 Further readings CMM Practices (version 1.1), CMU/SEI-93-TR-25. I. Sommerville, P. Sawyer, Requirements Engineering, John Wiley & Sons, Chichester, 

J. Nawrocki, Requirements Eng., Lecture 1 HomeworkHomework Write organisational policy for managing software requirements in your company or project team.

J. Nawrocki, Requirements Eng., Lecture 1 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?