01_ requirements engineering intro

Prof. Dr. Armin B. CremersSascha Alda

Organizational

Requirements

Engineering

Chapter 1Requirements Engineering

(Introduction)

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 2

Global View on Software EngineeringProblem, Solutions, Basic Techniques

Can you develop this?


Requirements

Software

Limitations of Non-engineered Software


Characteristics of Modern Systems

Volatile business environment subject to constant change - BPR; rapid IS development neededWide range of more complex system types CAD/CAM, GIS, Office Automation, CASE toolsIncreased use of complex data types - text documents, video, sound, graphics, spatial dataSophisticated user interfaces (GUIs)Client-Server environments / distributed systemsTendency for larger systems with complex and varied interrelationships among software components


Perspectives on Software Engineering:Quality of Software

The average software product released on the market is not error freeIrregular ShutdownsMisbehavior (MS Excel)

Updates are needed to meet users requirementsBug, Problems, Failures

Misunderstanding requirements leads to functional misbehaviorErrors in code

Standard software: 25 bugs per 1.000 lines of programWindows95: 200.000 errors (!) in 10 Millions lines

Exploding costs during developmentDelivery Date can not be met Organizational structure changes


Perspectives on Software Engineering:Definition

Software Engineering is a collection of techniques,methodologies and tools that help with the production of

a high quality software system with a given budget before a given deadline

while change occurs.


Perspectives on Software Engineering:Scientist vs. Engineer

Computer ScientistProves theorems about algorithms, designs languages, defines knowledge representation schemesHas infinite time…

EngineerDevelops a solution for an application-specific problem for a clientUses computers & languages, tools, techniques, and methods

Software EngineerWorks in multiple application domainsHas only 3 months...…while changes occurs in requirements and available technology


Perspectives on Software Engineering:A Problem Solving Activity

General Procedure for Problem-Solving activity:Formulate the problemAnalyze the nature of problem and break the problem into piecesSearch for solutions/Identify the most appropriate solutionsSpecify the solutions

The way:Modeling

Models abstract from a real life system that allows to answer questions about the systems:only relevant aspect are incorporated; Suppress irrelevant details

Knowledge AcquisitionNonlinear process: addition of new knowledge may invalidate old knowledge

Rationale ManagementCapturing the context in which decisions were made and the rationale behind these decisions


Perspectives on Software Engineering:A Problem Solving Activity

Problem solving needsNotation

Graphical or textual set of rules for representing a modelMethods:

Repeatable technique that specifies the steps for solving a specific problem

Methodologies: Collection of methods for solving a class of problems. Specifies how and when each method should be used

Tools: Instrument or automated systems to accomplish a method


Factors affecting the quality of a software system

ComplexityThe application (problem) domain is difficultComplex technologies (programming languages)The development process is very difficult to manageDomains are complex that no single person can understand itFixing a bug causes another bug

ChangeRequirements need to be updated when errors are discovered and when developers have a better understanding of the applicationProject constellation changes (staff turn-around) Technological changes (new standards, languages)


Dealing with Complexity

1. Modularization of the software life cycle2. Abstraction through modeling various aspects of a problem 3. Decomposition of the system to be modeled


Modularization:Software Development Process

Sub-systems

class...class...class...

SourceCode

Solution Domain Objects

SystemDesign

ObjectDesign

Implemen-tation Testing

ApplicationDomain Objects

Test Cases

? class....?

RequirementsElicitation

Use CaseModel

Analysis

Expressed in Terms of

Structured by

Realized by

Implemented by

Verified by


Abstraction:Limiting Complexity

Motivation: Inherent human limitation to deal with complexityA human being is able only able to perceive and to reason about 7 (+/- 2) things simultaneously. (the 7 +- 2 phenomena, Miller 1956)

Limit complexity of problem through abstraction: Models


Abstraction:Models are used to provide abstractions

System Model:Object Model: What is the structure of the system? What are the objects and how are they related?Functional model: What are the functions of the system? How is data flowing through the system?Dynamic model: How does the system react to external events? How is the event flow in the system ?

Task Model:PERT Chart: What are the dependencies between the tasks?GANTT Chart: How can this be done within the time limit?Org Chart: What are the roles in the project or organization?

Issues Model:What are the open and closed issues? What constraints were posed by the client? What resolutions were made?


Abstraction:Interdependencies of the Models

System Model (Structure,Functionality, Dynamic Behavior)

Issue Model(Proposals,Arguments,Resolutions)

Task Model(Organization,ActivitiesSchedule)


Abstraction:The “Bermuda Triangle” of Modeling

Task Models

PERT ChartGantt Chart

Org Chart

Issue Model

Constraints

Issues

Proposals

Arguments

Pro Con

System Models Object Model

FunctionalModel

Dynamic Model


Code

ForwardEngineering

ReverseEngineering


Which decomposition is the right one?

Decomposition:Overview

A technique used to master complexity (“divide and conquer”)Functional decomposition

The system is decomposed into modulesEach module is a major processing step (function) in the application domainModules can be decomposed into smaller modules

Object-oriented decompositionThe system is decomposed into classes (“objects”) Each class is a major abstraction in the application domainClasses can be decomposed into smaller classes


Decomposition:Overview

Both views are important during software life-cycle

Functional decomposition emphasizes the ordering of operationsVery useful at requirements engineering stage and high level description of the system. Functions are spread over the system Hard to maintain / change

Object-oriented decomposition emphasizes the objects that cause the operations.

Very useful after initial functional description Object DesignEncapsulates data and functions helps to deal with changeObjects don’t change often, but functions do


Decomposition: Functional Decomposition

Top Level functions

Level 1 functions

Level 2 functions

Machine Instructions

System Function

Load R10 Add R1, R10

Read Input TransformProduceOutput

TransformProduceOutputRead Input


Decomposition (Object-Oriented): What is This?


Decomposition (Object-Oriented): Model of an Eskimo

EskimoSize

Dress()Smile()Sleep()

ShoeSizeColorType

Wear()

*CoatSizeColorType

Wear()


Decomposition (Object-Oriented): Iterative Modeling then leads to ....

EskimoSize


CaveLightingEnter()Leave()

lives in

but is it the right model?

Entrance*

EnvironmentTemperature

LightSeasonHunt()

Organize()

moves around

WindholeDiameter

MainEntranceSize


Decomposition (Object-Oriented): Alternative Model: The Head of an Indian

IndianHair


MouthNrOfTeethSizeopen()speak()

*Ear

Sizelisten()

FaceNosesmile()close_eye()


Decomposition (Hierarchies):Part-of-Hierarchy

Computer

I/O Devices CPU Memory

Cache ALU ProgramCounter


First View on Requirements Engineering

Requirements Engineering is the first phase of the Software LifecycleProduction of a specification from informal ideasGoal: Requirements Specification

System requirements specification: requirements describe Software and HardwareSoftware requirements specification: describe only Software

RE is about what the system should do (not how to do it)

Key influencing factor to the development processFailures made here result in high costs in later development phasesSystem will meet the user/customer needs


Software Development Process:A Brief Overview

Sub-systems


SourceCode

Solution Domain Objects

SystemDesign

ObjectDesign

Implemen-tation Testing

ApplicationDomain Objects

Test Cases

? class....?


Use CaseModel

Analysis

Expressed in Terms of

Structured by

Realized by

Implemented by

Verified by


What is Requirements Engineering? (1/2)

Defining Requirements is a very challenging activityRequirements Elicitation needs Collaboration between different groups (stakeholder)

Developers (design knowledge, implementation knowledge)ClientsUsers (domain knowledge)

Two questions need to be answeredHow can we identify the purpose of a system? What is inside, what is outside the system? Very hard to decide!

Errors during Requirements ElicitationSystem fails to support users’ work: Missing or incorrect functionalityCorrections are expensive


What is Requirements Engineering? (2/2)

RequirementsEngineering

RequirementsElicitation + Requirements

Analysis

• Design basis for developers

• Technical specification of the system in terms understood by the developer (“Problem Specification”)

• Basis for Discussions with customer

• Definition of the system in terms understood by the customer (“Problem Description”)


Process of Requirements Elicitation:Products of Requirements Process

RequirementsAnalysis


ProblemStatement

Requirements specification: functional and non-functional requirements

Analysis Model: dynamic modelobject model


Requirements Engineering:Input and Output

Initial InputA Vision of a system to be created (vague)Different stakeholders with different interests

Problem StatementDesired Output

Specification as complete as possibleComplete coverage of the problem (all relevant requirements are captured)Complete and exact definition of each requirement


Starting with the Problem Statement

The problem statement is developed by the client as a description of the problem addressed by the systemA good problem statement describes

The current situationThe functionality the new system should supportThe environment in which the system will be deployedDeliverables expected by the clientDelivery datesA set of acceptance criteria


Starting with the Problem Statement:Ingredients

Current situation: The Problem to be solvedDescription of one or more scenariosSome initial requirements

Functional and Non-functional requirementsConstraints (“pseudo requirements”)

Project ScheduleMajor milestones that involve interaction with the client including deadline for delivery of the system

Target environmentThe environment in which the delivered system has to perform a specified set of system tests

Client Acceptance CriteriaCriteria for the system tests


Starting with the Problem Statement:Current Situation - Problem To Be Solved

There is a problem in the current situationExamples:

The response time in a travel booking system is far too slowThere have been illegal attacks to the system

A change either in the application domain or in the solution domain has appeared

Change in the application domainA new function (business process) is introduced into the businessExample: A function is provided for credit payment with fingerprint as authorization

Change in the solution domainA new solution (technology enabler) has appearedExample: New standards (implementation) for secure network communication


The Goal: Analysis Model (vs. Requirements Specification)

Both models focus on the requirements from the user’s view of the system. Requirements specification uses natural language (derived from the problem statement)The analysis model uses formal (Z, pi-calculus) or semi-formal notation (for example, a graphical language like UML)

Formal notations encompass an exact mathematical syntax and semantic

The starting point is the problem statement


Requirements and their Meaning

Definition of term “Requirement”A condition or capability needed by a user to solve a problem or to achieve an objectiveCondition or capability that must be met by a system

Satisfies a contract, standard, specification


Functional and Non-Functional Requirements

Functional requirementsDescribe the interactions between the system and its environmentindependent from implementation

Non-functional requirements (Most typical)User visible aspects of the system not directly related to functional behavior.Reliability, Performance, Availability, Supportability, Usability, Tailorability, Security

Pseudo requirements (Non-functional requirements B)Imposed by the client or the environment in which the system operatesLegal requirementsDesign and Implementation Constraints

Project Management (Non-functional requirements C)Budget, Release Date


Example: Library System

Idea: A Library Management System should be designed. Information on books, CDs, DVDs, Journals, etc. can be stored and retrieved

Possible Requirements:Searching by Title, Author, and/or ISDN should be possibleUser Interface should be web-based (accessible via WWW Browser)At least 20 transactions per seconds should be possibleAll services should be available within 10 minutesUsers have no access to personal data of other users

Problem Statement

functional requirement

Implementation requirement

performance requirement

availability requirement

Security requirement


What is usually not in the requirements?

System structure, implementation technologyDevelopment methodologyDevelopment environmentImplementation languageReusability

It is desirable that none of these above requirements are constrained by the client.


Software Requirements Standards

Many guidelines and standards exist that define the content and structure for “good” requirement specification document.Examples:

IEEE Recommended Practice for Software Requirements Specifications (IEEE Std-830)JPL Software Requirements Analysis Phase (JPL D-4005)


RSM is embraces the most common requirements standards into a single metamodel.

Model: an abstraction of a system that omits irrelevant detailsMetamodel: A model that explains a set of related models

RSM was proposed by Gibbels and PohlHierarchical Conception: Using classification, generalization, aggregation, and attributionCan help structuring requirements according to a specific scheme

Requirements Specification Model (RSM) 1/3:First view



(Taken from K. Pohl)

Abstract-Functional-RQ

Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 42(Taken from K. Pohl)



Some stakeholders in the RE Process

Client/CustomerContract partner who orders the software productDecides on budget and system functionality

Useruses the systemimportant for successful introduction (involvement during RE!)

User Advocatespeaks „two languages“: the one of the users, and the one of the developersshould be

technical experienced (what can be built)domain expert

Project Managercontract partnercontrols budget

Programmer/Software/Requirements Engineerhas knowledge on system development


Requirements Engineering Process:Four Phases (Another Perspective)

Elicitation Analysis/Negotiation Documentation Validation

Analysis Model

Requirements Document

System specification

User requirements

Existing systemsStandards


Requirements Engineering Process:Four Phases (Another Perspective)

Elicitation

NegotiationSpecification &Documentation

Validation &Verification

requirements engineer

systemuser

project manager/

user advocate

marketing expert

programmer

administrative officer

software engineer

system specialist

customer


Four Phases 1: Elicitation

Elicit requirements, needs, and constraintsCollecting knowledge about

domain (problem, laws)existing standards and systemsexisting specifications(may be in a variety of representations)

Using scenario-based approachesinterviewssimulations and prototypes

Participantsrequirements engineerUserclient

Elicitation




systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer

Elicitation




systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer


Four Phases 2: Negotiation

Reaching agreements on the requirements between all stakeholders involved

Make conflicts explicit (avoid emotional conflicts)Develop relevant alternatives (incl. underlying rationales)Make right decisions

Votings, Decision Support Systems etc.

Important: Recording and Documentation of Decisions (might be unstable)Participants

project managermarketing expertprogrammer

Elicitation




systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer


Four Phases 3: Specification and Documentation

No monolithic model, rather a bunch of modelstaking into account different perspectivesrepresenting intermediate as well as final results

Formal languages can be used (Consistency)In intermediate status inconsistencies may occur and must be toleratedParticipants

administrative officersoftware engineer(programmer)

Elicitation

Negotiation

Specification &Documentation



systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer

Elicitation

Negotiation

Specification &Documentation



systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer


Four Phases 4: Validation and Verification

Verification“am I building the product right?”Checking specification against formally defined constraints

Validation “am I building the right product?”Checking if the specification meets users’ needs

ParticipantsSoftware engineerSystem specialistCustomer

Elicitation




systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer

Elicitation




systemuser

project manager

marketing expert

programmer


software engineer

system specialist

customer


4 Worlds: Structuring the Context of Information Systems

Information Systems can be seen from different perspectivesSubject

Domain of the systemStakeholders = Subjects that are represented within systemExample: Car Recommender System, Cars

UsageStakehoders = Users of the systemUsage world can be outside the subject worldExample: Customers, Car Dealer…

SystemOperating and MaintainingExample: Car dealer’s system manager

DevelopmentExample: Developers, Architects, User Representative etc.

All four perspectives (and contexts) are dependent on each other


4 Worlds:Dependencies

Subject World System World Usage World

DevelopmentWorld

Legacy systemsMaintainability

ReuseConfigurations

Correct representationDomain knowledge

Impact privacy ownerships

ParticipationBusiness Processes

Needs

Representation accuracy,timeliness

Interface • Efficiency • Friendliness• PresentationFunctionality


Three Dimensions of Requirements Engineering or: Three Goals

SpecificationDeveloping as complete as possible requirements specificationInclude cost schedule

RepresentationProvide integrated representation formalisms of all aspects

Informal, semi-formal, formal as needed

Transformations between themAgreement

Accomplish common agreement on the final specificationAllow personal views meanwhile

Pohl et al.


Three Dimensions of Requirements Engineering: How to get there

Document the problem understanding reachedDifferent views on the specification

Graphical, textual, etc.Document the agreement reached

NegotiationsRationales

Be traceableContractsUnderstanding and acceptanceChange Management

Forward traceability (problem, refinement, requirement) and Backward traceability (requirement origin)

Pohl et al.


Some problems concerning requirements engineering

Goals have to be identifiedDifferent stakeholders have different interests

Complex dependenciesChanging interests and goals

Deficits in quality of descriptions and documentationsRedundanciesAmbiguitiesInconsistencies


Good Requirements

CompleteFunctionality is described completely

CorrectAccording to stakeholders‘intentions

ConsistentThere are no two requirements that can not be reached in one single system

CheckableRequirements can be used to generate tests on the final software (or sinlge modules)

ComprehensibleRequirements are to be understood by all stakeholders

NecessaryRequirement should be needed by customer and user

RealisableRequirements are to be realized in a software system

Traceable(discussed earlier)

Well-DefinedRequirement can only be understood in one single wayLeaves no space for interpretation


Overview of future lessons

Modeling with UMLSoftware Development Process ModelsRequirements ElicitationRequirements AnalysisRequirements VerificationRequirements ManagementMethods for Requirements EngineeringViewpoint-oriented Requirements MethodsNon-functional RequirementsInteractive SystemsGroupware SystemsPractitioners talks (tba)


Conclusions

Requirements Engineering is one of the “early phases” of software engineering processIterative processInteraction between

DevelopersCustomerUsers

Input: Wishes, Problems, Unclear requirements, etc.Output: Analysis Model


References

Brügge and Dutoit: „Object-Oriented Software Engineering“Chapter

Pohl, Klaus: „Requirements Engineering: An Overview“For download (personal use only)ftp://sunsite.informatik.rwth-aachen.de/pub/CREWS/CREWS-96-02.pdf

01_ requirements engineering intro

Documents