(1)

Requirements Analysis and Specification

Philip JohnsonCollaborative Software Development

Laboratory Information and Computer Sciences

University of Hawaiijohnson@hawaii.edu

(2)

Definitions Requirements Analysis:•The process of studying and analyzing the customer and user needs to arrive at a definition of software requirements.

Requirements Specification:•A document that clearly and precisely describes each of the essential requirements of the software and its external interfaces.

(3)

Many different approaches When do we do requirements analysis?

•Before starting implementation?•Before and during implementation?

How should we specify the requirements?•Through structured text?•Through formal notations and models?•Through informal note cards and acceptance tests?

When should we create the requirements specification?•Before starting implementation?•Simultaneously with implementation?•Don’t do it at all?

(4)

Some Schools of Thought The "Traditionalists"

•Upfront requirements prior to implementation•Well defined, structured process and products•30 years of experience for data processing domain

The "Model Driven Analysis/Architecture/Development" folks•Based upon UML notation•Object-oriented•Goal: semi-formal, semi-executable models that can be kept in sync with code

The "Agilists"•Minimal, just-in-time requirements•Requirements artifacts "thrown away" once code is available

(5)

A perspective on the "traditionalist" approach

(6)

Traditionalist Goals Generate a "software requirements specification" prior to implementation that provides enough details on system requirements to support: •contractual negotiation with a contractor

•detailed specifications for coding by an independent contractor

•detailed specifications for testing by an independent contractor

•end-to-end project planning and estimation

(7)

Processes Requirements elicitation•Identifying stakeholders, obtaining "raw" requirements from them via observation and interviews.

•Methods: Ethnography, Protocol Analysis, JAD

Requirements analysis•Link customer needs to product capabilities•Develop use cases (end-to-end scenarios)•Create logical and data models•Methods: QFD, SCRAM, SSAD

Requirements validation and prioritization•Resolve inconsistencies, multiple viewpoints

•Methods: CORE, WinWin

(8)

SRS Template 1. Introduction

•Purpose, intended audience, conventions, scope 2. Overall description

•Product perspective, features, users, operating environment, design constraints, documentation, assumptions

3. System features 4. External interfaces

•User, Hardware, Software, Communication 5. Nonfunctional requirements

•Performance, Safety, Security, Quality Appendix A: Glossary Appendix B: Analysis Models (Functional, Data, Use Case)

(9)

How do we fill out the template?

It’s ridiculously easy to create a WORTHLESS software requirements specification by mindlessly or haphazardly filling out the template to create an SRS that:•Does not identify all needed requirements•Specifies requirements that are not needed.•Specified requirements are ambiguous•Specified requirements conflict with each other

Better: perform various analyses of the system to “discover” the true requirements•Functional Analysis•Data Flow Analysis•Data Modeling•Use Case Analysis

(10)

Functional Analysis

(11)

Functional Analysis Goal:•Establish the functions required and the system boundary

Procedure:•Express functions in terms of converting inputs into outputs

•Break down top-level function into a set of sub-functions

•Draw a block diagram illustrating relationships between functions

(12)

Functional Analysis Model (top-level)

(13)

Functional Analysis Model

(14)

Data Flow Analysis

(15)

Data Flow Analysis Models processes and dataflows without sequence information.

Consists of context diagram and decomposable dataflow diagrams.•Describes I/O (data that flows across system or subsystem boundaries)

•External entities and resources•Data stores

(16)

Context Diagram

(17)

Level 0 Diagram

(18)

Enroll Students (Process 4)

(19)

Data Modeling

(20)

Logical Data Modeling Top-level "logical" data base design, including:•Specify all entities and relationships among them.

•All attributes for each entity are specified.

•The primary key for each entity specified.

•Foreign keys (keys identifying the relationship between different entities) are specified.

•Normalization if necessary

(21)

Physical Data Modeling Convert the logical data model to one that can be implemented in a database:•Specify all tables and columns.•Foreign keys are used to identify relationships between tables.

•Denormalization may occur based on user requirements.

•Physical considerations may cause the physical data model to be quite different from the logical data model.

(22)

Use Case Analysis

(23)

Use Case Analysis A use case is a single task, performed by the end user of a system, that has some useful outcome.

A collection of use cases provides a perspective on the dynamic behavior of the proposed system.

Use cases contrast with functional and data analysis, which provide perspectives on the static nature of the system.

(24)

Goals of Use Cases1. Develop an increased understanding

of the problem and the user interface. 2. Communicate with the end users to

make sure we're really solving their problems.

3. Organize the dynamic behavior of the design (and the resulting program) to reflect the actual business model in the user's mind. In other words, assure that the program actually does something useful for a real user.

4. Provide a road map and organizational framework for the actual development process.

(25)

Potential Use Case Components

Name•user-centric•"Make a deposit"

Description •What is accomplished

Desired outcome •What is the useful outcome

Basic actions•Details of use case

User goals •Why the user might do this

Participants/Roles•What role(s) are being taken

Dependencies •Subcases, precedes, follows, is/a, etc.

Preconditions•State that must exist before the use case

Postconditions •State what must exist after the use case

Business rules•Any relevent rules

(26)

Example Use Case Name:•Enroll in Seminar

Identifier: •UseCase-17

Description:•Enroll an existing student in a seminar for which she is eligible

Preconditions:•The student is registered at the University

Postconditions and desired outcome:•The student will be enrolled in the course she wants if she is eligible and room is available.

(27)

Example Use Case (cont) Basic course of action:•The use case begins when a student wants to enroll in a seminar.

•The student inputs her name and student number into the system via screen UI23:Security Login Screen.

•The system verifies that the student is eligible to enroll in seminars at the university according to business rule BR129: Determine Eligibility to Enroll [Alt Course A: Student not eligible to enroll]

•The system displays screen UI32:Seminar Selection Screen, which indicates the list of available seminars.

(28)

Example Use Case (cont.)•The student indicates the seminar in which she wants to enroll [Alt Course B: The student decides not to enroll]

: :•The system prints the enrollment statement.

•The use case ends when the student takes the printed statement.

Alt Course A: Student not eligible to enroll

: Alt Course B: The student decides not to enroll.

(29)

Use Case Description Tips The use case makes references to specific screens and reports.

The use case references business rules Each use case step reflects a single activity.

Use case steps are written in the active voice.

Alternate course of actions are infrequently used paths of logic.

(30)

Summary of "Traditionalist" approach

Create accurate, complete, internally consistent specification of system requirements.

Functional, Data Flow, Data Modeling, and Use Case analysis can help ensure completeness.

If successful, SRS can be •"handed off" to a subcontractor for implementation.

•used as the basis for price/schedule negotiation.

(31)

Model Driven Analysis/Development

(32)

MDA/MDD Benefit of traditionalist approach•Creates various “models” of the proposed system

Problem with traditionalist approach•Models are paper-based, “thrown out” as soon as implementation is underway.

•Large cost for very short-term use

Model-driven analysis/development:•Can we create models/abstractions of the system and its requirements that “survive” and “coexist” with implementation?

(33)

MDA Goals Separate domain concerns from platform concerns.

Improve communication between stakeholders by using notation more natural to domain.

Increase flexibility by allowing retargeting to different technologies.

Deliver systems faster by enabling automated generation of systems from abstractions.

Improve quality by decreasing manual implementation of system from specifications.

(34)

Example: Inteq MDA Framework

Note the presence of backward links! High level models should remain in sync with the implementation throughout the life of the system.

(35)

Model Driven Architecture (MDA)

Trademark of Object Management Group Provides an “open, vendor-neutral approach to the challenge of business and technology change. •Specifies “Platform Independent Models” (PIMs) that can be automatically translated into “Platform Specific Models” (PSMs) for .NET, J2EE, Corba, etc.

•PIMs specify business functionality and behavior separate from the technology-specific code that implements it.

•Key representations: UML, MOF, CWM-Unified Modeling Language-Meta-Object Facility-Common Warehouse Metamodel

(36)

MDA Example

http://www.omg.org/mda/mda_files/OMG-Information-Day-Sims_01-01.pdf

(37)

UML (OMG Specification) The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system.

The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components."

(38)

UML Notations Use Case Model:

•Describes boundary and interactions between system and users.

Interaction Model:•Describes how objects interact with each other.

State (Dynamic) Model:•State charts describe the states that classes assume over time.

•Activity graphs represent workflow Logical (Class) Model:

•Describes classes and objects in the system. Component (Physical) Model

•Describes hardware and software components Deployment Model:

•Describes physical architecture and how components map to it.

(39)

UML Examples: Class Diagram

(40)

UML Examples: Sequence Diagram

(41)

UML Example: Collaboration Diagram

(42)

UML Example: Detailed Class Diagram

(43)

MDA/MDD summary Approach is certainly promising•Provides abstraction (various perspectives)

•Provides automation (translation up/down)

Reality as of 2008: not quite there yet.•Many expensive commercial tools•ArgoUML (most popular open source UML tool)

•Eclipse integration through “Eclipse Modeling Framework”.

(44)

The Agilists

(45)

Agile Development Both traditional and model-driven approaches stress “Big Up Front Requirements/Design”

There is evidence that this leads to problems:•A 2001 study performed by M. Thomas in the U.K. of 1,027 projects showed that scope management related to attempting waterfall practices, including detailed, up-front requirements, was cited by 82 percent of failed projects as the number one cause of failure.

•Jim Johnson of the Standish Group notes: when requirements are specified early in the lifecycle that 80% of the functionality is relatively unwanted by the users.  He reports that 45% of features are never used, 19% are rarely used, and 16% are sometimes used.

(46)

Agile Requirements Analysis

Basic ideas:•Get active participation from stakeholders

•Use simple tools (whiteboard, etc.)•Model in a “just in time” manner•Don’t bother to “maintain” requirements, use them just as a means to getting to the implementation.

•Define requirements in small pieces

The XP approach:•User Stories•Customer Acceptance Tests

(47)

User Stories Similar to use cases, but not the same.

•Written by the customer•Take the place of a requirements document•Format of three sentences (or so) of text by the customer using the customer’s own terminology.

•Provides just enough detail so that developers can produce a reasonable estimate of the effort required to implement it.

•When starting to implement a User Story, you may need to do some just-in-time modeling (create a use case or UML diagram or whatever).

A user story is an informal statement of a requirement.•When scheduled for implementation, the customer must write a formal acceptance test which determines when the goals of the story have been fulfilled.

(48)

Example User Story

From http://www.xprogramming.com

(49)

Card, Conversation, Confirmation

Card:•User stories are written on cards. They do not contain all of the information associated with the requirement. They are a “token” representing the requirement.

Conversation:•The requirement is communicated from customers to programmers through communication.

Confirmation:•The customer defines acceptance tests that shows the behavior that the system must exhibit in order for the story to be implemented correctly.

(50)

Summary Traditionalists:

•Strengths: well established approach when you must “hand off” requirements to a contractor for implementation.

•Weaknesses: risk of incomplete/inaccurate requirements. MDA/MDD:

•Strengths: provides many different views of system.•Weaknesses: only partial tool support.

Agilists:•Strengths: avoids “big up front” costs and risks.•Weaknesses:

-risk of incomplete/inaccurate requirements and uncontrolled development hiding behind “agile” moniker.

-Certain nonfunctional attributes (security, safety) might require “big up front requirements/design”.

-Not clear how to deal with distributed development.