Documente Academic
Documente Profesional
Documente Cultură
Requirements
Software
Updates are needed to meet users requirements Bug, Problems, Failures Misunderstanding requirements leads to functional misbehavior Errors in code
Standard software: 25 bugs per 1.000 lines of program Windows95: 200.000 errors (!) in 10 Millions lines
Exploding costs during development Delivery Date can not be met Organizational structure changes
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 5
Engineer
Develops a solution for an application-specific problem for a client Uses computers & languages, tools, techniques, and methods
Software Engineer
Works in multiple application domains Has only 3 months... while changes occurs in requirements and available technology
Knowledge Acquisition
Nonlinear process: addition of new knowledge may invalidate old knowledge
Rationale Management
Capturing the context in which decisions were made and the rationale behind these decisions
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 8
Methods:
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
Change
Requirements need to be updated when errors are discovered and when developers have a better understanding of the application Project constellation changes (staff turn-around) Technological changes (new standards, languages)
10
Modularization of the software life cycle Abstraction through modeling various aspects of a problem Decomposition of the system to be modeled
11
Expressed in Terms of
Structured by
Realized by
Implemented by
Verified by
?
class....?
Subsystems
Source Code
12
Test Cases
Models
13
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 14
Functional Model
Dynamic Model
Issue Model
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering
Task Models
16
Decomposition: Overview
A technique used to master complexity (divide and conquer) Functional decomposition
The system is decomposed into modules Each module is a major processing step (function) in the application domain Modules can be decomposed into smaller modules
Object-oriented decomposition
The system is decomposed into classes (objects) Each class is a major abstraction in the application domain Classes can be decomposed into smaller classes
Decomposition: Overview
Both views are important during software life-cycle Functional decomposition emphasizes the ordering of operations
Very useful at requirements engineering stage and high level description of the system. Functions are spread over the system Hard to maintain / change
18
Read Input
Transform
Level 1 functions
Read Input
Transform
Produce Output
Level 2 functions
Load R10
Machine Instructions
19
20
21
moves around
Entrance
Windhole Diameter
MainEntrance Size
Size listen()
Ear
23
I/O Devices
CPU
Memory
Cache
ALU
Program Counter
24
RE is about what the system should do (not how to do it) Key influencing factor to the development process
Failures made here result in high costs in later development phases System will meet the user/customer needs
25
Expressed in Terms of
Structured by
Realized by
Implemented by
Verified by
?
class....?
Subsystems
Source Code
26
Test Cases
Requirements Analysis
Design basis for developers Technical specification of the system in terms understood by the developer (Problem Specification)
28
Desired Output
Specification as complete as possible
Complete coverage of the problem (all relevant requirements are captured) Complete and exact definition of each requirement
30
31
Project Schedule
Major milestones that involve interaction with the client including deadline for delivery of the system
Target environment
The environment in which the delivered system has to perform a specified set of system tests
32
A change either in the application domain or in the solution domain has appeared
Change in the application domain
A new function (business process) is introduced into the business Example: A function is provided for credit payment with fingerprint as authorization
34
35
availability requirement
38
39
RSM was proposed by Gibbels and Pohl Hierarchical Conception: Using classification, generalization, aggregation, and attribution Can help structuring requirements according to a specific scheme
40
User
uses the system important for successful introduction (involvement during RE!)
User Advocate
speaks two languages: the one of the users, and the one of the developers should be
technical experienced (what can be built) domain expert
Project Manager
contract partner controls budget
Programmer/Software/Requirements Engineer
has knowledge on system development
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 43
Elicitation
Analysis/ Negotiation
Documentation
Validation
Analysis Model
Requirements Document
System specification
44
customer
Elicitation
project manager/ user advocate
software engineer
Negotiation
marketing expert
administrative officer
Armin B. Cremers, Sascha Alda
programmer
Organizational Requirements Engineering 45
Elicitation
Negotiation
marketing expert
Using
scenario-based approaches interviews simulations and prototypes
administrative officer
programmer
Participants
requirements engineer User client
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 46
system specialist
Elicitation
project manager
software engineer
Negotiation
marketing expert
administrative officer
programmer
47
Elicitation
project manager
software engineer
Negotiation
marketing expert
Formal languages can be used (Consistency) In intermediate status inconsistencies may occur and must be tolerated Participants
administrative officer software engineer (programmer)
administrative officer
programmer
48
Verification
am I building the product right? Checking specification against formally defined constraints
Validation & Verification
Elicitation
project manager
software engineer
Negotiation
marketing expert
Validation
am I building the right product? Checking if the specification meets users needs
administrative officer
programmer
Participants
Software engineer System specialist Customer
49
Usage
Stakehoders = Users of the system Usage world can be outside the subject world Example: Customers, Car Dealer
System
Operating and Maintaining Example: Car dealers system manager
Development
Example: Developers, Architects, User Representative etc.
50
4 Worlds: Dependencies
Impact privacy ownerships
Subject World
System World
Usage World
Development World
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 51
52
Be traceable
Contracts Understanding and acceptance Change Management Forward traceability (problem, refinement, requirement) and Backward traceability (requirement origin)
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering
Pohl et al.
53
54
Good Requirements
Complete
Functionality is described completely
Necessary
Requirement should be needed by customer and user
Correct
According to stakeholders intentions
Realisable
Requirements are to be realized in a software system
Consistent
There are no two requirements that can not be reached in one single system
Traceable
(discussed earlier)
Well-Defined
Requirement can only be understood in one single way Leaves no space for interpretation
Checkable
Requirements can be used to generate tests on the final software (or sinlge modules)
Comprehensible
Requirements are to be understood by all stakeholders
Armin B. Cremers, Sascha Alda Organizational Requirements Engineering 55
Conclusions
Requirements Engineering is one of the early phases of software engineering process Iterative process Interaction between
Developers Customer Users
57
References
Brgge and Dutoit: Object-Oriented Software Engineering
Chapter
58