Requirement Analysis

REQUIREMENT ANALYSIS AND SPECIFICATION Sanjeev Sarma, Webx

1

Introduction •

Requirements Gatherings – – – –

•

Goals and Challenges Standard Approaches Example Requirements List Documenting Operational Requirements

Traditional Deliverables – –

Requirements Specification Documents Analysis Diagrams: • • •

–

2

Context Diagram, Entity Relationship Diagram, Data/Control Flow Diagram

Prototype

Requirements Gathering Analyzing Business Requirements

3

Goals of Requirements Gathering Find out what the users need  Document needs in a Requirements Specification 

     

 4

Avoid premature design assumptions Resolve conflicting requirements Clarify ambiguous requirements Eliminate redundant requirements Discover incomplete or missing requirements Separate functional from nonfunctional requirements

Ensure Requirements Traceability

Requirement Specifications seldom clearly capture customer needs

What user wanted  

5

How customer described it

How analyst specified it

How designer implemented it

Challenges in Requirements Gathering Consider a scenario illustrating the normal state of flux: Often you are using new business procedures, and your job has changed to head development of a brand new application your company has announced, and you are scheduling training for you and your team to master a new computer environment and new software development techniques and new tools using a new programming language, how dotraining you staff figure out end users, analysts, andcustomers, documentdesigners, how the new support application is staff marketing staff, staff, supposed to workimplementers, in a way maintenance that is clearly understood by: managers,

6

testers,

...?

Standard Approaches for Requirements Gathering Obtain requirements through user interviews Gathering representatives of stakeholders:

 

    

Executives Developer Maintenance users support staff ...

in one room at during uninterrupted session(s) to decide on requirements under an experienced leader/consensus maker: Joint requirements planning (JRP)  focus on what the system will do Joint application design (JAD)  focus on how the system will work produce a document which includes a list of requirements

Developing a Rapid Prototype

 7

Example Requirements List 1

(1 of 3)

Requirement

Comments

The system will support client inquiries from 4 access points: in person, paper-based mail, voice communication, and electronic communication (Internet, dial-up, and LAN/WAN

Four access points are how; we should focus on who needs access and from where

The telephone system must be able to support an 800 number system

Can't use 888 or 877? Missing who needs what kind of access from where Valuable statistics. This requirement is actually pretty good.

The telephone system must be able to handle 97,000 calls/yr. and must allow for a 15% annual growth. It is estimated that 19% of these calls will be responded to in an automated manner and 81% will be routed to call center staff for response. 50% of calls can be processed without reference to the electronic copy of the paper file, and approximately 50% will require access to system files. For the calls that require access to system information, response times for the electronic files must be less than 20 seconds for the first image located on the optical disk, less than 3 seconds for electronic images on a server, and less than 1 second for data files. 8

"optical disk" is a design assumption. Response times are good non-functional requirements if not linked to design assumptions (hardware device types).

Example Requirements List 1

(2 of 3)

Requirement

Comments

The telephone system must be able to support voice recognition of menu selections, touch-tone menu selections, and default to a human operator. The telephone menu will sequence caller choices in order of most frequently requested information to the least requested The telephone system must be able to provide a voice response menu going from a general menu to a secondary menu. The system must allow for the caller to provide address information through a digital recording and to indicate whether it is permanent. The system must allow for the caller to provide address information through voice recognition and to indicate whether it is permanent. The telephone system must be able to store and maintain processor IDs and personal identification numbers to identify callers and to route calls properly to the appropriate internal response telephone.

Pretty good one. Can you find anything wrong?

The telephone system must be able to inform callers of the anticipated wait time based on the number of calls, average duration of calls, and the number of calls ahead of them. 9

Great!

This seems to be trying to provide some pretty obvious advice to a dumb designer "Through a digital recording"? This is a design assumption Sound familiar? (It's redundant) Simplify it: "The system must be able to identify callers and route calls to the appropriate internal response telephone".

Example Requirements List 1

(3 of 3)

Requirement

Comments

The journal will contain entries for key events that have occurred within the administration of an individual's account. The system will capture date, processor ID, and key event description. The system will store pointers to images that are associated with a journal entry as well as key data system screens that contain more information regarding the entry.

This is a design for a journal. Why have it? What is its purpose?

If an individual double-clicks on an event in a member's journal, the system will display the electronic information and the images associated with the event. The system will restrict options on the information bar by processor function. When an icon is clicked, the screen represented by the icon will be displayed and the system will display appropriate participant information.

Double-click is a user interface design assumption This one has many user interface design assumptions.

Note: Each requirement should have a number to provide traceability. 10

Example Requirements List 2 (1 of 2) Requirement

Comments

6.7.1.2 The system must provide the capability to capture all of the customer transactions for fiscal 6.7.1.3 The system will year provide restricted remote inquiry access (via dial-in) to view images and data separately or 6.7.1.4 The system will simultaneously barcode documents automatically prior to distribution. At a minimum, the codes will be used to identify to which work queue the documents should be routed within the organization when they are returned

Too vague. Implies fiscal year has some impact on how customer transactions are organized, but does not specify what that is. Implies some data entry, but needs to be stated more specifically. May be trying to make a statement about volume, meaning old transactions can't be archived until they are a year Saying "restricted" is OK, but details about the restriction (who old? can, who can't) should be stated clearly in this context. Also vague is the reference to remote inquiry. How remote? Saying "remote access" when referring to mobile employees working in the field but still within a couple of miles of the office or worldwide access. Can have huge implications on system. Makes several technical design assumptions. Barcoding is a solution, not a requirement. This system probably needs a way to identify each document uniquely, but it doesn't have to be barcodes. If all existing systems use document barcoding (not the case with this system), should write a nonfunctional requirements that states, "Unique identification of all documents will be done through barcoding". By specifying barcoding in the functional specifications, changing to glyphs, optical character recognition (OCR) will be more difficult. The reference to queues makes an assumption about a workflow-package-oriented system. Better to state: "At a minimum, the unique id will ensure routing to a specific worker in the organization when documents are returned."

11

Example Requirements List 2 (2 of 2) Requirement

Comments

6.7.1.5 When a workflow is initiated, the system must be able to pre-fetch the documents that are in electronic image format by document type or grouping of documents by process 6.7.1.6 The system must create an entry in the journal file whenever a letter is created

Look at references to workflow. Requirements document has specified a workflow solution! This whole entry is suspicious. Seems to be saying that we must cache documents by two different criteria: by type or by process. Criteria are good requirements, but caching (pre-fetching) is a solution to address performance problems. Assumes presence of a journal file containing entries inserted when a letter is created. Seems focused on front end ("do this") instead of back end ("in order to get this"). Why put entries in a journal file? To create a list of all letters created, when and by whom? This would make a better, clearer requirement. Seems to be focused on how rather than what. Instead of specifying the steps a system must go through, clearly document the end in mind. Example: "When a new document image is brought into the system, it should be routed to the worker who has the account open for the same SSN as the new document and should be made obvious to that worker. If no worker has an open account, the document should be made available to any worker."

6.7.1.7 System must maintain list of current, open work processes and identify work process to be executed and workflow queue for process. When documents are scanned, system determines whether there is a process open for that SSN. If there is, the system routes document to appropriate workflow queue, displays work process script, and 12 highlight current work process.

Obtaining Operational Requirements Problems with traditional ways of specifying problems:    

customer may not adequately convey the needs of the user. developer may not be an expert in the application domain, which inhibits communications. users and customers may not understand the requirements produced by the developer developer's requirements specifications typically specifies system attributes such as:  Functions  Design constraints  Quality attributes  System interfaces and  Performance factors

but typically contains little or no information concerning operational characteristics of the specified system. 13

Guidelines for Operational Concept Document Operational Concept Document (OCD) describes the mission of the system, its operational and support environments, and the functions and characteristics of the computer system within an overall system. Several guidelines and standards exist to prepare an OCD:  Mil-Std

498 for Department of Defense SW development  IEEE Standard 1498 for commercial SW development,  AIAA OCD 1992 for the American Inst. of Aeronautics and Astronautics (for embedded real-time systems)  ConOps 1997 Concept of Operations Document Guidelines proposed by Fairley and Thayer [FT97] because they felt the above guidelines were Systems-oriented and developer-oriented instead of user-oriented. 14

The Concept of Operations Document Identifies  

classes of users and modes of operation      

Normal mode Emergency mode Maintenance mode Backup mode Degraded mode Diagnostic mode

Users communicate   

essential needs desirable needs -- prioritized optional needs -- prioritized

Prioritized user needs provide the basis for  

establishing an incremental development process, and making trade-offs among operational needs, schedule and budget.

15

Concept Analysis Concept Analysis Team, include representatives from User organization  Training  Buyer organization  Operational support  Developer organization or Development Experts/Consultants Results of concept analysis are recorded in the ConOps document written in narrative prose using users' language, and using visual forms (diagrams, illustrations, graphs, etc.) wherever possible. Each operational scenario needs a test scenario to validate the system in user's environment. Validate proposed system by walking thru all scenarios, include both normal and abnormal operations:  Exception handling  Stress load handling,  Handling incomplete data  Handling incorrect data. 16 

Outline for a Concept of Operations Document 1 Scope 1.1 Identification 1.2 System Overview 1.3 Document Overview 2 Referenced Documents 3 The Current System or Situation 3.1 Background, Objectives, & Scope

5

5.2 Operational Policies & Constraints 5.3 SystemDescription of Proposed 5.4 5.5

Modes of Operation User Classes 5.5.1 Organization Structures

3.2 Operational Policies & Constraints 3.3 Description 3.4 Modes of Operation 3.5 User Classes 3.5.1 Structure Organizational

3.5.2 Profiles of User Classes 3.5.3 Interactions Personnel3.5.4 Other Involved

3.6 Support Environment 4 Justification Proposed for and Nature of Changes & New Features 4.1 Justification 4.2 Description 4.3 Priorities among Changes/ Features 174.4 Changes/Features Considered but

Concepts of Operations for the New or Modified Proposed System 5.1 Scope Background, Objectives &

5.5.2 Profiles of User Classes among 5.5.3 User Classes Interactions 6 7

8

5.6 Other Involved Personnel 5.7 Support Environment Proposed Operational Scenarios Summary of Impacts 7.1 Operational Impacts 7.2 Organizational Impacts 7.3 Impacts During Developments Analysis of Proposed System 8.1 Summary of Improvements

Rapid Prototype

[www.dilbert.com ]

Having a prototype during requirements phase gives you something to work from when communicating with the users and client, and results in a user-centered GUI design 18

Traditional Expressions of Functional Requirements  Requirements specifications 



Context Diagram 





Useful for technical people but tend to confuse users Useful in design of non-object-oriented systems

Entity-relationship diagrams (ERD) 



Specifies users, software, hardware that interface with system

Data-flow Diagrams (DFD) 



Hard to read. Contract-like.

Critical to database design but are not easily understood by users

Prototypes 

Good communication tool to obtain information from user.



Great for proof-of-concept tasks. Useful in developing user interface designs.



19

Unified Modeling Language (UML)

20

UML Diagrams 

Instead of the Context, Data-Flow and Entity-Relationship Diagrams used in Structured Analysis, UML produces 9 types of diagrams         

21

Use Case Diagram Sequence Diagram Collaboration Diagram State chart Diagram Activity Diagram Class Diagram Object Diagram Component Diagram Deployment Diagram

Use Cases

22

History of Use Cases 

Ivar Jacobson and his team at Ericsson in Sweden introduced Use Cases in their book: 



I. Jacobson, M. Christerson, P. Jonsson, and G. Overgaard. Object-Oriented Software Engineering: A Use Case Driven Approach, ACM Press, 1992.

Use Cases were included as part of their overall system development lifecycle methodology, called Objectory, which was sold to Rational Software. Now Use Cases are part of the Rational Unified Process, created by the "three amigos": 

23

I. Jacobson, G. Booch and J. Rumbaugh. The Unified Software Development Process, Addison-Wesley, 1999.

What is a Use Case? The Use Cases describe the behavior of a system from a user's standpoint using actions and reactions.  The Use Case Diagram defines the system's boundary, and the relationships between the system and the environment: 

  



different human users roles interact with our system other software systems/applications hardware systems/devices

Use Cases support the specification phase by providing a means of capturing and documenting requirements

24

Use Case Deliverables 

There are two parts to document a use case: 

the use case diagram,  



the use case itself   

25

provides visual overview of important interactions captures scope (identifies external entities) documents in a textual form the details of the requirements, what the use case must do. A use case is actually a page or two of text representing each oval in the use case diagram A project should have a standard template for use cases.

Use Case Diagram system

actor Real Estate System

Buyer

Sell Property Seller

Advisor

use case interaction

26

Use Case Documentation Template Use Case Number: A unique numeric identifier Use Case Name: A unique descriptive identifier Iteration: Facade (Outline and high-level description), Filled (Broader, deeper), Focused (Narrower), Finished Summary: Briefly state the purpose of the use case in one or two sentences to provide a high-level definition of the functionality provided by the use case. Basic Course of Events:

1.

Include the following: 4.1 What interaction the use case has with 1. This is a numbered list. The use case number is the actors used togetherfor with this number to provide 4.2 What data is needed by the use case requirements traceability 4.3 When and how the use case starts and 2. Write this as a flow of events describin what the ends system should do, not how the system should do 4.4 The normal sequence of events for the it. use case 3. Write it in the language of the domain, not 4.5 The description of alternate or exceptional flows, technical jargon Alternative Paths: What happens if ... invalid information is entered, unusual types what happens if ...of processing occurs, or uncommon conditions occur, how is the flow completed? 5. The description of each step grows in detail Exception Paths: What happens if... an error occurs, how is flow affected? asthe analysis progresses Extension Points: Describes an <<extend>> relationship, shows steps which are extended by optional steps in another case Trigger: Describe entry criteria for use case, may describe business need, may be time-related, or completion of other case Assumptions: Critical section for project manager. Things (out of scope of system) you assume to be true but might not be true Preconditions: List things that must be in place before interaction can occur. (Part of contract between use case & outside world. Postconditions: List things that will be satisfied if use case is completed successfully. Independent of alternative paths taken. Related Business Rules: Written and unwritten company business rules that relate to requirements presented in this use case Author: This is placed at the bottom, together with the date to allow critical information to be speed read Date: Facade, Filled, Focused, Finished dates

27

Use Case Documentation Example Use Case Number: 1 Iteration: Filled

Use Case Name: Sell Property

(Four stages of iteration are Facade, Filled, Focused, and Finished)

Summary: System Context Use Case. The seller lists the property, a buyer purchases the property, and the agent guides them through the process and offers advice, caution, and recommendations Basic Course of Events: 1. Seller selects an agent 2. System responds by assigning an agent and notifying the seller's agent. 3. Seller lists the property to sell. 4. System responds by displaying this property in the property listing and linking it for searches 5. Buyer selects an agent. 6. Buyer reviews the property listings by entering search criteria 7. System displays properties matching buyer's search criteria 8. Buyer finds a property and makes an offer on it. Alternative Paths: N/A Exception Paths: N/A Extension Points: N/A Trigger:

N/A

Assumptions:

N/A

Preconditions:

N/A

Postconditions:

N/A

9. System responds by notifying seller and seller's agent 10. Seller responds to the offer with a counteroffer. 11. System responds by notifying buyer and buyer's agent. 12. Buyer and seller agree to terms 13. System responds by recording the agreement 14. Buyer indicates a loan is required 15. System responds by locating an appropriate loan provider 16. Buyer and loan provider agree to loan terms. 17. System responds by recording terms of loan 18. Buyer and seller close on property. 19. System responds by recording details of close.

Related Business Rules: N/A Author: Rumpel Stilskin Date:

28

March 10, 2001 – Facade; April 20, 2001 -- Filled

A Simpler Use Case Template A simpler template for Use Case documentation is recommended by Terry Quatrani [TQ98]  For each use case: 

X

Flow of Events for the Use Case X.1 Preconditions X.2 Main Flow X.3 Subflows (if applicable) X.4 Alternative Flows

where X is a number from 1 to the number of the use case 29

Associations in Use Case Diagram Associations can exist  between an actor and a use case,  between use cases, and  between actors  Types of Use Case Associations  Communicates between actor and use case  named or unnamed relationship showing participation of actor in use case, use a solid line connecting actor to use case  Generalization between actors  Adornments = Stereotyped Associations between use cases  <<extend>> indicates relationship between use cases in which a special use case (the non-arrow end) extends an original use case (the arrow end)  <> reuses steps in a use case instead of cut-and-pasting steps into multiple use case documents, by pulling out common steps into a new use case and specifying with an arrowed line the <> association between this new use case and those use cases requiring the steps  <<uses>> An instance thetarget source use case includes behavior described byofthe Shows a stereotyped generalization relationship between 30 use cases 

Example of Generalization between Use Case Actors

Service Representative

Customer Service Representative

31

Field Service Representative

Example of Communicates Use Case Relationship

Sell Property Buyer

Triggers Buyer

32

Sell Property

Example <<uses>> and <<extends>> Use Case Relationships Transfer by computer Remote Customer

Local Customer

<<extends>> Transfer

<<uses>>

Identification

33

Example <> and <<extends>> Use Case Relationships Schedule Customer Appointment Office Administrator

<>

Schedule Designer

<> Enter Customer Order

34

<<extends>> Schedule Recurring Customer Appointment

The Use Case View for the Case Study: Course Registration System

35

The Actors 

In the Course Registration System, answering the questions suggested to find actors yields:     



Students want to register for courses Professors want to select courses to teach Registrar must create the curriculum and generate a catalog for the semester Registrar must maintain all the information about courses, professors, and students Billing System must receive billing information from the system

Actors identified from above: 

Student – person registered/registering in classes at the University



Professor – person certified to teach classes at the University

36 

Registrar – person who maintains the Course

The Use Cases  Answering

yields:

the questions to find use cases

The Student actor needs to use the system to register for courses  After the course selection process is completed, the Billing System must be supplied with billing information  The Professor actor needs to use the system to select the courses to teach for a semester, and must be able to receive a course roster from the system  The registrar is responsible for the generation of the course catalog for a semester, and for the maintenance of all information about the curriculum, the students, and the professors needed by the system  Based on the needs, the following cases are identified: 1. Register for courses 2. Select courses to teach 3. Request course roster 4. Maintain course information 5. Maintain professor information 6. Maintain student information 37 7. Create course catalog 

The Flow of Events

38

(1 of 3)

The Flow of Events

39

(2 of 3)

The Flow of Events

40

(3 of 3)

Use Case Diagram (1 of 2)

41

Use Case Diagram (2 of 2)

42

Select a Use Case and Sub-Flow   

Look at a use case: Select Courses to Teach Select a subflow: Add a Course Offering Although the flow is written sequentially, in the real world many steps may occur concurrently The professor logs onto the Registration System and enters password. The system verifies the password is valid (E1) and prompts the professor to select the current semester or a future semester (E2). The professor enters the desired semester. The system prompts the professor to select the desired activity: ADD, DELETE, REVIEW, PRINT, or QUIT. The professor chooses ADD, the S-1: Add a Course Offering subflow is selected. S-1 Add a Course Offering The system displays the course screen containing a field for a course name and number. The professor enters the name and number of a course (E-3). The system displays the course offerings for the entered course (E-4). The professor selects a course offering. The system links the professor to the selected course offering (E-5). The use case then begins again. E-3: An invalid course name/number is entered. The user can re-enter a valid name/number combination or terminate the use case E-4: Course offerings cannot be displayed. The user is informed that this option is not available at the current time. The use case begins again. E-5: A link between the professor and the course offering cannot be created. The information is saved and the system will create the link 43 at a later time. The use case continues

Case Studies

44

Thank You

45