Requirement Analysis and Specification Session 2005/ 2006 Pascal Fenkam
Adm inistration I ntroduction &
Administrative details � Lecturer-in-charge � Dr. Pascal Fenkam Argentinierstr. 8/ 1841, 3rd flloor � Office hours: Thursday: 14h-15h � Studienassistenten � Daniel Fede � Leo Brunnhofer � Michael Halwax � Two mandatory group assignments � Discussion via TUWIS � 2 hours lectures (x 6)
RULES & REGULATIONS � Please be PUNCTUAL for all your classes. � Switch off your m obile phones. � Concentrate during lecture sessions. � EXAM TI PS are given throughout the sessions � Attendance is highly recommended. � Behavior in Lectures : � Listen & Ask!
Text Books Managing Software Requirements: A Use Case Approach (Dean Leffingwell and Don Widrig), Chapters 8-13
Text Books Problem Frames. Analyzing and Structuring software development problems (Michael Jackson), Chapters 1-8
Lecture Plan � Lecture � Tutorial � Group Assignments � Final Examination
Course Assessment Coursework � Tutorial Group Assignment 45% Final Exam 55% 100% Total
Your Responsibilities the lecture’s aim is to explain the syllabus � coverage for a topic and place it into context. It is not meant to tell you everything you need to � know about the topic. In order to gain sufficient depth of knowledge, you � are expected to read up other text and references and practice your analytical skills in solving the tutorial questions and case studies.
Dishonesty � We view any act of dishonesty with grave concern. � Any student caught committing any form of dishonesty will be deemed to have failed the examination. � Dishonesty includes plagiarism, misconduct during examination and theft of other student’s work.
Q & A
Introduction to requirements engineering
Objectives � Introduce the notions of � requirements engineering (RE) � system requirements � Put RE into a broader context of system engineering � Introduce the notion of � processes and � process models for RE
The Requirements Problem US expenses for IT applications � development: $ 250 billion/ year Standish Group: � � 31 % of projects are canceled before ever get completed � 22 % are completed but with cost and schedule overrun or without meeting expectation
The Requirements Problem Requirements errors are the most common, most � serious problems and the most costly to fix. Standish Group: the three most cited factors: � � Lack of user input (13 % of all projects) � Incomplete requirements and specs (12 % ) � Changing requirements and specs (12 % ) A few skills can significantly reduce requirements � errors and improve software quality.
Requirements Time Acceptance test Maintenance Unit test Design Coding The Requirements Problem Cost of Requirements Errors .1 -.2 2 0 .5 2 5 1
The Requirements Problem The requirements don’t reflect the real needs of � the customer for the system. � Result: Late nights, Systems are late, unreliable, don’t meet customers needs, lot of canceled projects, com plete frustration. Requirements are inconsistent and/ or incomplete. � It is expensive to make changes to requirements � after they have been agreed or/ and implemented � Redesign � Recoding � Retesting
Requirements Engineering Needs Problem Dom ain Features Softw are Requirem ents Solution Dom ain
Requirements Engineering User Needs: � � A reflection of the business, personal, or operational problem that must be addressed in order to justify consideration, purchase, or use of a new system Development teams need to understand true needs � User Needs are often vague an ambiguous � � I need easier way to understand the status of my inventory/ library � I’d like to see a big increase in the productivity of sales order entry
Requirements Engineering Feature: a service provided by the system that � fulfills one or more stakeholder needs � Each user must have an account in the library system � Manual control of doors during fire emergency � Linux compatibility Unfortunately, users often state neither features � nor their needs but something in between � I want a vehicle with ABS � I need a new GUI-based order entry screen Users transform needs into believed features � � Advantages: users are experts in their domains, such features are easy to discuss and document. � Caveat: the feature may not be (and often is not) the solution � You are right, but you still lose!
Example of Features Define what the library system is required to do and � the constraints under which it is required to operate The system shall maintain records of all library � materials including books, serials, newspapers and magazines, video and audio tapes, reports, collections of transparencies, computer disks and CD-ROMs. The system shall allow users to search for an item by � title, author, or by ISBN. The system’s user interface shall be implemented using � a World-Wide-Web browser. The system shall support at least 20 transactions per � second. The system facilities which are available to public users � shall be demonstrable in 10 minutes or less.
Classes of custom systems Information systems � � Primarily concerned with processing information which is held in some database. Embedded systems � � Systems where software is used as a controller in some broader hardware system Command and control systems � � A combination of IS and ES where the ES provides information which is collected, stored, and used to make decisions via the IS
The systems engineering process System System requirements validation engineering Architectural System design integration Requirements Sub-system partitioning development Software requirements engineering
Requirements Engineering Process
Types of stakeholders Software engineers responsible for system development � Software Architects, Designers, Testers, etc. � System end-users who will use the system after it has � been delivered Managers of system end-users who are responsible for � their work Those managers who pay for the development of the � system External regulators who check that the system meets its � legal requirements Domain experts who give essential background � information about the system application domain
Process � A process is an organised set of activities which transforms inputs to outputs � Process descriptions encapsulate knowledge and allow it to be reused � Examples of process descriptions � Instruction manual for a dishwasher � Cookery book � Quality manual for software development
RE process - inputs and outputs Existing systems information Agreed Stakeholder requirements needs Requirements System Organisational engineering process specification standards System Regulations models Domain information
RE process variability RE processes vary radically from one organisation � to another Factors contributing to this variability include � � Technical maturity � Disciplinary involvement � Organisational culture � Application domain There is therefore no ‘ideal’ requirements � engineering process
RE process activities Requirements elicitation � � Needs and features discovered through consultation with stakeholders Requirements analysis and negotiation � � Requirements are analysed and conflicts resolved Requirements documentation � � Requirements document are produced (including specifications) Requirements validation � � The requirements document is checked for consistency and completeness
Spiral model of the RE process Informal statement of Decision point: requirements Accept document or re-enter spiral Requirements elicitation Requirements analysis and negotiation START Requirements Agreed document and requirements validation report Requirements validation Requirements documentation Draft requirements document
RE process problems Lack of stakeholder involvement � Business needs not considered � Lack of requirements management � Lack of defined responsibilities � Stakeholder communication problems � Poor quality requirements documents �
Process improvement Process improvement is concerned with � modifying processes in order to meet some improvement objectives Improvement objectives � � Quality improvement � Schedule reduction � Resource reduction
Planning process improvement What are the problems with current � processes? What are the improvement goals? � How can process improvement be introduced � to achieve these goals? How should process improvements be � controlled and managed?
Good practice for RE process improvement RE processes can be improved by the systematic � introduction of good requirements engineering practice Each improvement cycle identifies good practice � guidelines and works to introduce them in an organisation
Examples of good practice guidelines Define a standard document structure � Define policies for requirements management � Use checklists for requirements analysis � Use scenarios to elicit requirements � Specify requirements � Reuse requirements �
Recommend
More recommend
