Software EngineeringSoftware Engineering

Analysis (Concepts and Principles)James Gain

(jgain@cs.uct.ac.za)

http://people.cs.uct.ac.za/~jgain

ObjectivesObjectives

Motivate for analysis

Introduce the general analysis process Requirements elicitation

Developing prototypes

Creating Analysis Models

Producing a Requirements Specification

Identify key principles that are applied to analysis

No Formal Customer RequirementsNo Formal Customer Requirements

Recipe for disaster:

1. The customer has only a vague idea of what is required

2. The developer is willing to proceed with the “vague idea” on the assumption that “we’ll fill in the details as we go”

3. Repeata. Customer keeps changing requirements

b. Developer is “ratcheted” by these changes, making errors in specifications and development

Until the project flops

Software Requirements AnalysisSoftware Requirements Analysis

Identify the “customer” and work together to negotiate “product-level” requirements

Build an analysis model (warning: not object-oriented) focus on data

define function

represent behavior

Prototype areas of uncertainty

Develop a specification (semi-formal contract between customer and developers) that will guide design

Conduct formal technical reviews

The Analysis ProcessThe Analysis Process

the problemrequirements

elicitation

build aprototype

createanalysismodels

developSpecification Review

Requirements ElicitationRequirements Elicitation

Communicate with the customer(s) to elicit the requirements of the system

Informal approach - meetings and interviews Ask questions:

Context: “who is behind the request for this work?”, “who will use the solution?”, “Is there another source for the solution?”

Specific: “What problems will this solution address?”, “What are the performance issues or constraints?”

Meta-questions: “Are you the right person to answer these questions?”, “Should I be asking you anything else?”

BUT really only good for the initial meeting Problem: customers communicate wants not needs Other structured approaches: FAST, QFD, Use-Cases,

questionnaires, hidden cameras!

require.elicitation

build aprototype

analysismodels

developspec.

Review

Facilitated Application Specification Facilitated Application Specification Techniques (FAST)Techniques (FAST)

Overcome the “us and them” mindset of developers and customers

Create a joint team of customers and developers that work together to: Identify the problem

Propose elements of the solution

Negotiate different approaches

Specify a preliminary set of solution requirements

SoftwareEngineering

Group

CustomerGroup

FAST GuidelinesFAST Guidelines

Meetings have a specific structure: Rules for preparation and participation A “facilitator” and “definition mechanism”

Predominantly used in IS community - implemented as Joint Application Development (JAD)

Rules:1. participants must attend the entire meeting

2. all participants are equal

3. preparation is as important as meeting

4. all pre-meeting documents are to be viewed as “proposed”

5. off-site meeting location is preferred

6. set an agenda and maintain it

7. don’t get mired in technical detail

Quality Function DeploymentQuality Function Deployment

Quality management technique that ranks customer requirements as:1. Normal requirements – if these are present the customer is

satisfied

2. Expected requirements – often implicit, absence will cause much “wailing and gnashing of teeth”

3. Exciting requirements – above and beyond the user’s expectations

Components: Function deployment determines the “value” (as perceived by the

customer) of each function required of the system

Information deployment identifies data objects and events

Task deployment examines the behavior of the system

Value analysis determines the relative ranking of requirements

Use-CasesUse-Cases

A collection of scenarios that describe the thread of usage of a system

Each scenario is described from the point-of-view of an “actor” “Role” is a better word A person or device that interacts with the software in some way

Each scenario answers the following questions:What are the main tasks or functions performed by the actor?

What system information will the actor acquire, produce or change?

Will the actor inform the system about environmental changes?

What information does the actor require of the system?

Does the actor wish to be informed about unexpected changes?

Method adopted in this course

PrototypesPrototypes

If the requirements are uncertain then consider prototyping during analysis

Build a prototype Show it to the customers Adapt it to their needs

Features: Rapid (gloss over imperfections, ignore design issues)

Built for change (will have to undergo quick iterations)

Throwaway (must not live beyond requirements phase)

Invaluable for mock-ups of the user interface

require.elicitation

build aprototype

analysismodels

developspec. Review

Pros and Cons of PrototypingPros and Cons of Prototyping

Warning label: Do not use the prototype as the legal specification document Do not develop the prototype into the product (good to code it in a

different language from the main development)

Case Studies Report: Enthusiastic reception from users Improved usability of final software 2/3 of the study didn’t discard the prototype

Prototyping might lead to unfortunate user expectations about change

The prototype can be retained as long as it undergoes rigorous design and quality assurance. But this defeats the purpose of prototyping

Create Analysis ModelsCreate Analysis Modelsrequire.

elicitation

build aprototype

analysismodels

developspec. Review

Data Model

BehavioralModel

FunctionalModel

Analysis PrinciplesAnalysis Principles

Focus on the essence of the problem (no implementation details)

Examine “what” rather than “how” Understand the problem before you begin to create the

analysis model Develop prototypes that enable a user to understand how

human-machine interaction will occur Record the origin of and the reason for every requirement Use multiple views of requirements Prioritize requirements Work to eliminate ambiguity (primary advantage of

Formal Mathematical Specification)

Procedural ModelsProcedural Models

Data: define data objects, attributes and relationships traditionally use Entity Relationship diagrams

Function: identify functions that transform data objects indicate how data flows through the system represent producers and consumers of data traditionally use Data and Control Flow Diagrams

Behaviour: indicate different states of the system specify events that cause the system to change state traditionally use State Transition Diagrams

Partitioning the Procedural ModelsPartitioning the Procedural Models

Problems are often too large and complex to be understood as a whole

Create a hierarchical representation of the requirements

refine each model to represent lower levels of abstraction refine data objects

create a functional hierarchy

represent behavior at different levels of detail

Requirements Spec.Requirements Spec.

End product of analysis

The requirements specification is the official statement of what is required of the system developers

Should include both a definition and a specification of requirements

It is NOT a design document. As far as possible, it should set out WHAT the system should do rather than HOW it should do it

require.elicitation

build aprototype

analysismodels

developspec. Review

Users of the Requirements Spec.Users of the Requirements Spec.

System CustomersSpecify the requirements and read them to check

that they meet their needs. They specify changes to the requirements.

ManagersUse the requirements document to plan a bid for the system and to plan the system development process

System Engineers Use the requirements to understand what system is to be developed

System Test Engineers

System Maintenance

Engineers

Use the requirements to develop validation tests for the system

Use the requirements to help understand the system and the relationship between its parts

Properties of the SpecProperties of the Spec

Separate functionality from implementation Specify external system behaviour Specify implementation constraints Be easy to change Serve as reference tool for maintenance Record forethought about the life cycle of the

system Characterise responses to unexpected events Recognize that “the specification must be tolerant

of incompleteness and augmentation”

Spec StructureSpec Structure

Introduction – set out goals, objectives and context of the software

Information Description – document data content, flow and structure

Functional Description – A description of the functions required to solve the problem

Behavioural Description – operation of the software as a result of internal and external events

Validation Criteria – often overlooked, how is a successful implementation going to be recognized

Bibliography and Appendix – reference to related documents, definition of terms, graphical models

Requirements ReviewRequirements Review

This is conducted by both customers and developers

Once complete the Software Requirements Specification document is “signed off” by the customer and developer

But Spec is difficult to test in a meaningful way

require.elicitation

build aprototype

analysismodels

developspec.

Review