csci 6231 software engineering ( chapter 10?) requirements workflow instructor: morris lancaster

CSCI 6231 Software Engineering(Chapter 10?) Requirements Workflow

Instructor: Morris Lancaster

January 2011 CSCI 6231 Chapter 10 2

Overview

• Slides on Text Material are Backup.

• Introduction

• Discuss– Eliciting requirements from clients

– Modeling requirements

– Reviewing

– Documenting

Introduction

• Requirements Analysis– Capture what the customer wants

– Negotiate/iterate on what we and the customer can agree to

– And which is testable

January 2011 CSCI 6231 3

Importance of Requirements

“The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.”

Brooks, Frederick P., Jr. (1987). “No silver bullet: Essence and accidents of software engineering.” IEEE Computer, 20(4),

April 1987: pp 10-19.


Importance of Requirements

• In 1994, the Standish Group surveyed over 350 companies about their over 8000 software projects to determine status of the industry

– 31% cancelled before completed

– 9% delivered on time and within budget in large companies

– 16% delivered on time and within budget in small companies

• Top reported factors contributing to failures– Incomplete requirements 13.1% **

– Lack of user involvement 12.4% **

– Lack of resources 10.6%

– Unrealistic expectations 9.9% **

– Lack of executive support 9.3%

– Changing requirements and specifications 8.7% **

– Lack of planning 8.1%

– System no longer needed 7.5% **?


Requirement

• An expression of desired behavior– Objects/Entities

• States that objects can be in

• Functions performed to change states or characteristics

– Non-functional requirements

• Timeline– Extracted from the user

– Refined at specification time (allocated to software)

– Baselined as trace-back-to during implementation

– Are basis for testing

– Can change at any time


Requirements Extraction

• An expression of desired behavior– Objects/Entities

• States that objects can be in

• Functions performed to change states or characteristics

• Timeline– Extracted from the user and other inputs

– Refined at specification time (allocated to software)

– Baselined as trace-back-to during implementation

– Are basis for testing

– Can change at any time



• Sources– Stakeholders

• The person/organization paying for the system

• Customers of the above who will purchase the system

• End users of the system

• Domain Experts

• Market Researchers

• Lawyers/Auditors

• Software Engineers

– Consistency?• One approach is to encourage inconsistency during the requirements

process and document stakeholder views, maintaining them



• Sources - continued– Documentation

• Existing procedures/processes/system

– Observation of the current system• User performance of tasks

– Apprenticeship with users

– Products from Domain Specific Strategies such as JAD

– Brainstorming



• Issues– Requirements are not well formed or well understood at

the beginning

– Customers are not able to describe what they want or need

– It is difficult for the software engineer to rapidly understand someone else’s business concerns

– Customers use their jargon and domain specific thought models as assumed baselines

– The software engineer’s jargon and domain specific thought models interfere



• Types– Functional

– Non functional (quality requirements, etc)

• Constraints– Design constraints (previously made, platform or

product)

– Process constraints (how we build it, customer whims, agile)



• Types (more)– Design constraints

• Physical environment

• Interfaces

• Users

– Process constraints• Resources

• Documentation

– Quality constraints• Performance

• Security



• Types (more)– Quality constraints

• Performance

• Security

• Reliability and availability

• Maintainability

• Precision and accuracy

• Time to delivery/cost



• Requirements Documents– Requirements Definition

• A complete listing of everything that the client wants to achieve

– Requirements Specification• Restates the requirements as a specification of how the

proposed system shall behave



• Requirements Characteristics– Are the requirements correct? – review by all

– Are the requirements consistent? – any conflicts, have views been reconciled?

– Are the requirements unambiguous ?– be able to see the person on the hill with the telescope

– Are the requirements complete? – ranges of inputs/outputs and operational environments specified with expected behaviors

– Are the requirements feasible?

– Is every requirement relevant?

– Are the requirements testable?

– Are the requirements traceable/



• Testable– Once a requirement is stated, we should be able to

determine whether or not a proposed solution meets the requirements

– Evaluation must be objective• Atmospheric humidity information must be accessible

immediately

• Atmospheric humidity information must be retrieved within 5 seconds of a request


Modeling Notations

• Modeling– Implements repeatable processes that can be used to

achieve results within a given set of bounds

– Many specification and design notation methods


Modeling Notations

• Entity Relationship Diagrams (Chen – 76)– Entities, attributes, relationships

– UML Class Diagram• Name, attributes, operations, associations, generalizations,

subclasses

• Event Traces– Sequence of events

– Message Sequence Charts


Modeling Notations

• State Machines– State transitions, possible state– UML Statechart Diagrams– Petri Nets

• Data-Flow diagrams– Data centric view with processes shown– Use Case Diagram

• Formal Approaches– Logic (temporal)– Set Theoretic (Z)– Algebraic Specifications


Modeling Notations

• Also there are methodologies which incorporate multiple views

• The objective is to have a set of notations that can be used throughout the development or life cycle of the initiative

• An important characteristic is the ability to flesh out requirements iteratively (and follow ons to design and implementation) using all of the same tools we began with and that there are relationships (informational) between the notations/tools


Prototyping

• Throwaway– We must introduce it as a visiting orphan, or

– We must tear it from the tight grip of the user and throw it in the trash in front of them

• Evolutionary– The user will watch their child grow


Requirements Definition

• Outline general purpose and scope

• Describe the background and rationale behind the proposed system

• Describe the essential characteristics of an acceptable solution

• Describe the environment in which the system will operate

• Outline any customer proposals for solving the problem

• Document all assumptions made about the environment


Requirements Specification

• Document interfaces, inputs and outputs in detail, destinations, etc

• Restate functionality in terms of the interfaces’ inputs and outputs

• Devise fit criteria for each customer quality requirement.


Verification and Validation

• Validation– Is it valid?

– Do the requirements accurately reflect the customer’s

• Verification– Do the documents/artifacts produced thus far conform


Verification and Validation Techniques

• Validation– Walkthroughs and formal inspections

– Reading

– Interviews

– Reviews

– Checklists

– Scenarios

– Prototypes

– Simulation


Verification and Validation Techniques

• Verification– Cross-referencing artifacts

– Simulation

– Checks for consistency and completeness

– Checks for unreachable states, situations

– Computer aided verification

– Mathematical Proofs


Summary

• Requirements definition and specification documents must describe the problem, leaving solution selection to the designers

• Large number of sources and means for collecting requirements

• Many different types of definition and specifications techniques

• Specification techniques differ in their tool support, maturity, understandability, ease of use, and mathematical formality.

• Requirements questions can be answered using models or prototypes.

• Requirements must be validated to ensure they accurately reflect the customers’ expectations
