chapter 1 requirements engineering (introduction) file01/03/2016 · chapter 1 requirements...
TRANSCRIPT
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?
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 3
Requirements
Software
Limitations of Non-engineered Software
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 4
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 5
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 6
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.
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 7
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 8
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 9
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 10
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)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 11
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 12
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 13
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 14
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?
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 15
Abstraction:Interdependencies of the Models
System Model (Structure,Functionality, Dynamic Behavior)
Issue Model(Proposals,Arguments,Resolutions)
Task Model(Organization,ActivitiesSchedule)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 16
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
class...class...class...
Code
ForwardEngineering
ReverseEngineering
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 17
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 18
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 19
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 20
Decomposition (Object-Oriented): What is This?
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 21
Decomposition (Object-Oriented): Model of an Eskimo
EskimoSize
Dress()Smile()Sleep()
ShoeSizeColorType
Wear()
*CoatSizeColorType
Wear()
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 22
Decomposition (Object-Oriented): Iterative Modeling then leads to ....
EskimoSize
Dress()Smile()Sleep()
CaveLightingEnter()Leave()
lives in
but is it the right model?
Entrance*
EnvironmentTemperature
LightSeasonHunt()
Organize()
moves around
WindholeDiameter
MainEntranceSize
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 23
Decomposition (Object-Oriented): Alternative Model: The Head of an Indian
IndianHair
Dress()Smile()Sleep()
MouthNrOfTeethSizeopen()speak()
*Ear
Sizelisten()
FaceNosesmile()close_eye()
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 24
Decomposition (Hierarchies):Part-of-Hierarchy
Computer
I/O Devices CPU Memory
Cache ALU ProgramCounter
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 25
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 26
Software Development Process:A Brief Overview
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 27
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 28
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”)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 29
Process of Requirements Elicitation:Products of Requirements Process
RequirementsAnalysis
RequirementsElicitation
ProblemStatement
Requirements specification: functional and non-functional requirements
Analysis Model: dynamic modelobject model
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 30
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 31
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 32
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 33
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 34
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 35
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 36
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 37
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 38
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.
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 39
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)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 40
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 41
Requirements Specification Model (RSM) 2/3:First view
(Taken from K. Pohl)
Abstract-Functional-RQ
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 42(Taken from K. Pohl)
Requirements Specification Model (RSM) 3/3:First view
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 43
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 44
Requirements Engineering Process:Four Phases (Another Perspective)
Elicitation Analysis/Negotiation Documentation Validation
Analysis Model
Requirements Document
System specification
User requirements
Existing systemsStandards
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 45
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 46
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
NegotiationSpecification &Documentation
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Elicitation
NegotiationSpecification &Documentation
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 47
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
NegotiationSpecification &Documentation
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 48
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
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Elicitation
Negotiation
Specification &Documentation
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 49
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
NegotiationSpecification &Documentation
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Elicitation
NegotiationSpecification &Documentation
Validation &Verification
requirements engineer
systemuser
project manager
marketing expert
programmer
administrative officer
software engineer
system specialist
customer
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 50
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 51
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 52
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.
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 53
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.
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 54
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 55
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 56
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)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 57
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
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 58
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