Requirements Analysis

Transcription

1 Requirements Analysis Based on K. E Wiegers Software Requirements, Chap 5, 14 D. Leffingwell & D. Widrig, Managing Software Requirements A use case approach, Chap 5

2 Requirements Analysis The process of classifying requirements information into various categories, evaluating requirements for desirable qualities, representing requirements in different forms, deriving detailed requirements from high level requirements, negotiating priorities, and so on. [K. Wiegers]

3 Requirements Analysis Objectives of analysis detect and resolve conflicts between requirements discover the bounds of the software and how it must interact with its environment elaborate system requirements to derive software requirements such that managers can construct realistic project estimates and developers can design and implement and test

4 Requirements Analysis Takes elicitation notes as input However analysis and elicitation feed each other Elicitation Elicitation notes Prompt for questions and points to ponder Analysis Requirements specification

5 Requirements Analysis Includes: Problem analysis Development of Product Vision and Project Scope Requirements Classification Organize requirements in coherent clusters Allocate requirements to subsystems Conflict resolution Reconciling several stakeholders views Requirements Prioritizing Finding the most important requirements Determine which features will be included in each release Analysis goes in parallel with modeling (specification) Modeling help in most of the analysis activities

6 Requirements Classification Organization of related functional requirements in logical clusters Possible organizational options features use cases mode of operation by user class by subsystem... Makes it easy to understand the product intended capabilities It is more effective to manage and prioritize large chunks rather than single requirements

7 Conflicts Resolution Possible conflicts among Stakeholders between supplier and customers about costs, benefits, risks power struggle within customer organization, conflicts with other projects about resources conflicting goals, features, requirements...

8 Conflicts Resolution Conflict resolution involves negotiation group discussion have each party explain what they believe the other party wants and why analyze each party goals, find solutions that don't conflict but support everybody goals

9 Requirements Prioritizing Why Prioritize Requirements? Too many requirements requirements from different sources Limited resources (budget, time) Developers don't know the value of the requirements Customers don't know the complexity of implementing requirements

10 Requirements Prioritizing Prioritizing is needed, but: how to know which requirements are more important? what criteria to use for prioritizing? when each requirement would be considered (iteration)

11 Requirements Prioritizing Difficulties Different stakeholders may have different priorities Organizations lack systematic data, metrics techniques to help the prioritizing process Prioritizing often carried out informally Wrong idea that everything in a specification can be done however, in practice, some requirements are left out when deadline can't be meet

12 Requirements Prioritizing Deciding which requirements really matter Or those that need to be implemented in the current release Also referred to as requirements triage Needed because there will almost always be the need f or trade offs: Required functionality vs. time and resources

13 Requirements Prioritizing Process Must be simple and fast, for industry adoption Yield accurate and trustworthy results Should consider issues of: Importance of requirement to the user (maximize) Cost of implementation (minimize) Time to delivery (minimize)

14 Importance of Prioritizing Prioritizing requirements help: Making acceptable tradeoffs among goals of cost and time to market Project planning in allocating resources based on requirements importance to the project as a whole

15 Approaches Requirements Analysis Structured analysis (1970) Object oriented analysis (1990) Problem Frames (1995)

16 Structured Analysis Data oriented approach Based on analysis of flow of information Models Dataflow diagram (DFD) flow of information in system Entity Relation Diagrams (ERD) describe data Data dictionary define all data elements State Diagram describe state based behavior

17 Structured Analysis Mainly used for information systems Extensions have been developed for real time systems Analysis consists on modeling current system (can be a manual system) New system derived from understanding current system What if there is no current system?

18 Approaches Structured Analysis Structured Analysis and Design Technique (SADT) Doug Ross Structured Analysis and System Specification(SASS) Yourdon and DeMarco Structured System Analysis (SSA) Gane and Sarsan Structured Requirements Definition (SRD) Ken Orr Structured Analysis / Real Time (SA/RT) Ward and Mellor Modern Structured Analysis Yourdon

19 Structured Analysis SASS Steps 1. Analysis of current physical system DFD to show current data flow through the organisation Shows physical organisational units or individuals 2. Derivation of logical model Logical functions replace physical units 3. Derivation of proposed logical model DFD modified to reflect new proposed system 4. Implementation of new physical system Several alternatives considered

20 Modeling of new system Structured Analysis 1. Produce statement of purpose (objective of new system) 2. Develop essential environmental model (of new system) Context diagram (DFD 0) Data dictionary Event list 3. Develop essential behavioural model (of new system) Data flow diagram(s) (modelling the functionality of the new system) (DFD 1, DFD 2,...) Mini specs (for the transformation processes) State transition diagrams (for any control processes) Entity relationship diagram Supporting text (?) (Note, these documents constitute the analysis and the specification documentation)

21 Structured Analysis Dataflow notation T r a n s f o r m I n p u t O u tp u t T e r m in a to r D a ta d ic tio n a r y

22 Structured Analysis example (Bray 2004) Statement of purpose A software based system is required to control lifts (elevators) manufactured by Skyhi Lifts. Lifts are constrained to shafts (one lift per shaft) and moved up and down by winding motors (one winding motor per lift). Users can call lifts by pressing buttons either inside the lift (a lift button) or outside the lift (a floor button) and there is an indicator system to show the users the current position of the lift.

23 Structured Analysis example (Bray 2004) Context diagram (DFD 0) sensor motor signal winding motor lift button lift sensor signal lift control system indicator signal indicator button signal door signal floor button floor button signal door

24 Structured Analysis example (Bray 2004) Data Flow Diagram (DFD 1) lift button floor button sensor lift button press floor button press sensor signals monitor requests despatch lifts monitor lifts request request lift status lift detail lift detail request queue request lift data lift status request cancel control lifts lift detail lift position control indicators indicator command door command door controller motor command winding motor indicator

25 Structured Analysis example (Bray 2004) Entity Relationship Diagram shaft lift door building sensor lift button indicato r set floor button floor indicato r

26 Mini specs Structured Analysis example (Bray 2004) monitor buttons loop if lift_button press received if relevant lift/floor not requested record request if floor_button press received if relevant floor/direction not requested record request

27 Structured Analysis Problems Over emphasis on modelling (there s more to analysis!) Models the pre existing solution system (rather than the Domain) Essentially process based models (encourage structural model of the pre existing system) Difficulty in integrating DFD and ERD models No explicit mention of requirements! (an implicit assumption that the pre existing system already meets the requirements apart from not being computer based!) (SSADM eventually added the Problem/Requirements List PRL) This assumption is carried through into design (the new system inherits its basic structure from the pre existing system) Lack of a behavioural (functional) specification

28 Object Oriented Analysis Based on modeling a system as objects relations between objects and interaction of objects. Concepts Object: major actors, agents, and servers in the problem space of the system Class: abstraction of objects (type) Encapsulation: packaging of data and operations, detail of operations are hidden Inheritance: define classes inclusion

29 Object Oriented Analysis Main steps " Identify core classes within problem domain " Model relationships between classes (class diagram) " Define the attributes associated with each class " Determine relevant operations for each class " Define the messages that may be passed between objects (interaction diagram, state diagram)

30 Object modeling Library example (Sommerville & Kontoya) A library system is intended to provide its users with the ability to automate the process of: " Acquiring library items " Cataloguing library items " Browsing library items " Loaning library items Library items comprise published and recorded material The system will be administered by a member of the library staff Users must register with the system administrator before they can borrow library items

31 Library example (contd.) Library users are drawn from three primary groups: Students, Members of staff and External users All library users have as part of their registration: Name, Library number, Address, Account In addition the following information also required for registration: Students Degree programme and admission number. Staff Staff number External users Employer details

32 Step 1 Initial classes identified L ib r a r y u s e r L ib r a r y ite m L ib r a r y s ta f f A c c o u n t

33 Step 2 Relationships between classes We can identify the following relationships from the partial requirements: (i) A library user borrows a library item (ii) A library item is recorded or published (iii) The system administrator registers the library user (iv) Library users are students, staff and external users (v) The system administrator catalogues the library items (vi) The library assistant issues the library items

34 Step 2 Basic object model showing attributes and relationships Library user Name Address Library id 1 borrows 1,N Library item Title Classmark Call Number N browses 1,N N N N N registers Account loaned item due date receives issues 1 Library staff staff id catalogues

35 Step 2 Inheritance for Library user Library user Name Address Library id Account loaned item id due date Student Degree programme Admission number Staff Staff number External Employer name Employer address

36 Step 2 Inheritance for library item Library item Title Classmark Published item Publisher Y ear Recorded item Format Length of play Contents Book A uthor ISBN number Journal V olume Issue

37 Step 3 Identifying the attributes Attributes can be revealed by the analysis of the system requirements For example, it is a requirement that all library users must be registered before they can use the library " This means that we need to keep registration data about library users " Library users may also be provided with an account to keep track of the items loaned to them Library item has the attributes; title, description and classmark The library user class has the attributes; name, address and library id

38 Step 4 Object operations This step is intended to describe operations to be performed on the objects Certain operations are implicit from the object structure " These include operations for accessing and modifying the attribute values. These operations are assumed and we need not show them explicitly in the model One way of identifying operations is by modelling the messages that may be passed between the objects

39 Step 4 Messages between objects L ib r a r y u s e r 1. is s u e 2. r e tu r n 3. b r o w s e L ib r a r y ite m 1. r e g is te r 2. q u e r y L ib rary staff 1. a c q u ir e 2. c a ta lo g u e 3. d is p o s e

40 Step 4 Operations for library user and library staff Library user N ame A ddress Library id register query A ccount loaned item id due date compute fine Student D egree programme A dmission number Staff Staff number External Employer name Employer address

41 Step 4 Operations for library item Library item Title Classmark acquire issue return dispose catalogue Published item Publisher Year Recorded item Format Length of play Contents Book Author ISBN number Journal Volume Issue

42 Step 5 Define the messages that may be passed between objects Library User (LU) System Library staff Requests library item (1) Scans in LU registration (2) accepts registration (3) rejects registration (3) verifies item loan to LU (4) loans item (5) denies loan (5)

43 Problems with Object- Oriented Analysis Not really analysis Most OOA approaches actually address High level design Assume a pre existing requirements document Use Cases analysis used to supplement OOA Scaterring and Tangling effects

44 Problem Domain Analysis (PDOA) Approach developed by Michael Jackson (1995) The focus of the approach consists in representing and analyzing a problem using a context diagram represented as a problem diagram There are classes of problems with a standard solution similar idea as for design patterns each class is described by a generic problem diagram called a problem frame

45 PDOA The problem and Solution The Problem is here Connections between the world and the Computer The Solution is here The world outside the computer The Computer and its Software Where? How? What?

46 PDOA The Problem Developing software is building a machine Machine One problem, one machine The machine is a general purpose computer specialized by software The machine may be distributed One computer may support many machines Problem decomposition gives many sub problems and so many machines

47 PDOA The Problem Developing software is building a machine to solve a problem in a given domain ( a part of the world) Machine Machine Domain The machine and the problem domain interact at an interface of shared phenomena (events, states, etc.) Usually we need to structure the problem domain and to structure the problem into subproblems The machine in one subproblem may be a part of the problem domain in another subproblem

48 PDOA The Problem Developing software is building a machine to solve a problem in a given domain ( a part of the world) Machine Machine Domain to meet a customer s needs(the Machine Domain Requirement requirement) The customer s requirement is for some effect (or property or behavior) in the problem domain means that the requirement adds a constraint to the domain s intrinsic properties or behavior

49 Problem Types Michael Jackson suggests a classification of problems as (there may be more) Control : Required behaviour Commanded behaviour Workpiece Information Continuous display Requested reports Transformation Connection

50 Problem Types The classification helps with the development process by providing specific guidance for each type of problem decomposing complex problems in a logical way Problem Frame model is used to characterise the problem Model the problem context model the relationships between domains

51 Problem Frame A problem frame is a kind of pattern. It defines an intuitively identifiable problem in terms of its context and the characteristics of its domains, interfaces and requirements. Domain and interface characteristics are based on a classification of phenomena. (M.A. Jackson) Correspond to problem types Control Workpiece Information Transformation Connection

52 Problem Frames Example Transformation Frame Transforms given input data to produce new output data according to some pre defined rules. mapping rules (requirements) input data transformation system output data

53 Problem Frames Example Transformation Frame Problem Frame for a program that produces a credit card statement, given a file of transactions statement production rules transaction file credit card statement program statement file

54 Problem Frames Notation Domains are shown thus : Domain name The SS (machine) is a special domain and has a special symbol: Solution system name Domains (apart from the SS) that can be designed by the developer (realised domains): Domain name Relationships (interactions) between domains: connection not explicit: shared phenomena

55 Problem Frames Notation The requirements are represented thus : Requirements Where the requirements reference (refer to) a domain this is shown as: Where the requirements constrain (impose upon) a domain this is shown as:

56 Control Frame Required behaviour: controls some part of reality according to defined rules Control machine Controlled domain Required behavior Example: Program sequencer Washing machine Washing rules

57 Control Frame Commanded behaviour: controls some part of reality according to operators commands required behaviour controlled domain control system source of commands (user) Examples: engine management system, process control,...

58 Information Frame Continuous (automatic) reporting: automatically provides information about some part of reality information function (requirements) real world reports requests (user) information system Requested (upon demand) reporting: provides information about some part of reality upon request

59 Information Frame For an information system, it is the real world s data that is significant The IS will often contain a model of the real world data but note that there are two models they may vary in structure and value! information function real world requests reports update mechanism (connection system) informatio n system

60 Workpiece Frame Examples: CAD tools System must perform directed operations upon objects that exist only within the system. Provides for a user to create and edit documents operation effects (requirements) CASE tools source of commands (user) workpiece system office utilities (word processors, spreadsheets) workpiece (document) desk top publishing, web site production tools...

61 Workpiece Frame Example Grading guidelines Professor Grade Editor Student GradeBook inclusion

62 Transformation Frame Transforms given input data to produce new output data according to some pre defined rules. mapping rules (requirements) input data transformation system output data

63 Connection Frame This, common version resembles the transformation frame but there is a crucial difference: the transformation system generates new data from old, the connection system just moves (logical) data from A to B The requirements will concern the acceptable delays and distortions that the system can introduce requirements source connection system destination

64 Multi Frame Problems Most real life problem domains cannot be fitted with a single, simple problem frame The problem must be partitioned and (overlapping) frames fitted to the recognisable parts (This provides a very useful strategy for handling complex problems divide and conquer!)

65 Multi Frame Problems Example lift system control + information lift controller (information system part) sensor s behavio ur rules informati on function lifts motors lift controller (control part) indicato rs door controlle rs button s users

66 PDOA method 1. Collect basic information and develop problem frame(s) in order to establish the type of the PD 2. Guided by the PF type(s), collect further detail and develop a description of the relevant characteristics of the PD (This description may well incorporate conventional models such as Context diagrams, ERDs etc.) 3. In conjunction with the foregoing, collect and document the requirements for the new system