Model-Based Requirements. Engineering. Planned topics. Introduction. Process. developer. time. modelling formalisation. fuzziness.

Transcription

1 Model-Based Requirements Engineering Tutorial by Kristian Sandahl Andreas Borg Planned topics Overview of Requirements Engineering Requirements as model entity Domain models and system models in UML Use-case modelling Requirement model traceability Short introduction to formal methods 1 Non-functional requirements Process fuzziness customer developer elicitation time specification modelling formalisation Introduction Models supplement natural language Models support both elicitation and design The boundaries between specification and design have to be decided There are high transition costs from functional to objectoriented models UML is becoming the standard notation

2 Develop complementary system models Benefits: Forces analysis from different views Different readers take different views Implementation: The UML 4+1 model Combination of older diagrams Drawbacks: Different readers make different interpretation Normally weak exception handling Hard to model nonfunctional requirements Use structured methods for system modelling Benefits: Standard documentation Wide-spread understanding Supporting tools and methods are available Comes often with defined transition to design Implementation: UML Problems: Only partial systems can be modelled Can imply a paradigm shift You can become tool dependent UML 4+1 Model Views: Logical view: which parts belong together? Process view: what threads of control are there? Development view: what is developed by whom? reuse issues Physical view: which part will execute where? + Use-case model: required system from the user s point of view. static and dynamic Model the system s environment Benefits: Shows interfaces Shows what is not in the system Easy to relate to business process Implementation: consult stake-holders prototype-and-test Problem: work is related to change take contact sell specify detail ship invoice schedule drive 2

3 Model the system architecture Benefits Partition of the requirements Gives an overview Identify cross-cutting requirements Problem: Involves trade-off between non-functional requirements Please, note: We assume a very high level of architectural description Document the links between stakeholder requirements and system Benefits: Problems: Increased traceability Reveals problems Prepares negotiation Controlled change Reader s navigation aid to models Maintenance Complex mapping Assumption: There exist high-level stake-holder requirements Use a data dictionary Benefits: consistent name use name traceability possible Problems: Maintenance Implementation: Class diagram Future: Domain-specific ontologies Content: Name Aliases Type Description Rationale Constraints Links Requirements as model elements 3

4 Hyperbolic net in Focal Point Example: Feature in RequisitePro 4

5 Attribute-driven RE R1 Realised Name Description Planned Origin Models Specified Tasks Context of use User categories Captured Education level Work experience Computer experience Use-case diagram Actor: a user of the system in a particular role. Can be human or system. Borrow copy of book BookBorrower Detail of use-case A BookBorrower presents a book. The system checks that the potential borrower is a member of the library, and that he/she doesn t already have the maximum permitted book on loan. This maximum is six unless the member is a staff member, in which case it is 12. If both checks succeed, the system records that this library member has this copy of the book on loan. Otherwise it refuses the loan. 5

6 Use-case diagram for the library Library system BookBorrower Reserve book Borrow copy of book Return copy of book Browse Browser Extend loan Borrow journal Update catalog JournalBorrower Return journal Librarian Extension points Condition: {customer selected HELP} extension point: Selection Perform ATM transaction extention points Selection <<extend>> on-line help Relations between use-cases Please, Please, keep keep as as simple simple as as possible. possible. Extend loan <<include>> BookBorrower Borrow copy of book <<include>> Check for reservation Reuse Stereotype: extended classification of meaning <<extend>> Refuse loan Separating scenarious Identifying classes: noun analysis A BookBorrower presents a book. The system checks that the potential borrower is a member of the library, and that he/she doesn t already have the maximum permitted book on loan. This maximum is six unless the member is a staff member, in which case it is 12. If both checks succeed, the system records that this library member has this copy of the book on loan. Otherwise it refuses the loan. book real noun handled by the system system meta-language borrower already actor library member handled by the system staff member handled by the system checks event copy of book handled by the system 6

7 The single class model Book name title: String attribute copiesonshelf() : Integer borrow(c:copy) operations More relations between classes 1..* 10..* Topic Link aggregation 1 1..* Encylopedia Volume composition Board 1 Square row:{1,2,..8} column:{1,2,..8} 1 qualified association Copy is a copy of 1..* {xor} 1..* is a copy of 0..* 0..* Book constraint Journal The library class model Book is a copy of borrows/returns LibraryMember * 1 1..* Copy generalisation borrows/returns MemberOfStaff * Journal Classical use-case specification max 40 pages 7

8 Also in Requisite Pro Combining fragments of interaction diagrams in UML 2 SD processorder :Order :TicketDB :Account create ref Get existing customer data loop loop [get next item] reserve(date,no) loop condition add(seats) answer destruction Sequence diagram with timing constraints amember: BookBorrower thelibrarymember: LibraryMember thecopy: Copy thebook: Book A {C-A < 5s} borrow(thecopy) 1: oktoborrow 2: borrow {borrowed borrowed < 1s} 2.1: borrowed C More fragments of interaction diagrams in UML 2 :Order :TicketDB loop [get next item] reserve(date,no) guard condition alt [available] add(seats) reject [unavailable] nested conditional alternate branches 8

9 State diagram For class Copy: object message this object start marker return()/book.returned(self) on loan on the shelf borrow()/book.borrowed(self) state event, causing transition action, reaction to the event Deployment diagram hardware august: Workstation lotta: PC <<LAN>> <<artifact>> <<artifact>> State diagram with guards For class Book: Wiht Wiht OCL, OCL, Object Object Constraint Constraint Language, Language, this this becomes becomes very very powerful powerful returned() returned() not borrowable borrowable borrowed()[last copy] borrowed()[not last copy] 9 <<use>> Traceability analysis design implementation vertical traceability horizontal traceability

10 Traceability methods Explicit links provided by a tool Textual references Name tracing using a pre-defined convention System knowledge and domain knowledge used by experienced people The traceability matrix D1 D2 D3 D4 D5 D6 D7 R1 x x R2 x x R3 x R4 x x x R5 x x R6 x x x R7 Oops! Cross-referencing traceability R1: The system shall print all invoices at the department. (D1, D2,...) D1: The system takes data from the customer data base and template A to print external invoices. (R1) D2: The system prompts the user for input and use template B for internal invoices. (R1) Benefits from good traceability Fulfilment of requirements can be assured Design rationale can be sought in affected requirements Change impact analysis forwards and backwards Cost estimations are made possible System understanding becomes easier Maintenance and testing are facilitated 10

11 Troubles with traceability Hard to know what to trace Hard to maintain tracing information People don t trust tracing information Hard to visualize traces It is thought of as an internal quality factor Is traceability item-wise even possible? Types of traceability Practical investigation in traceability From Lindvall and Sandahl: Practical Implications of Traceability, Software Practice and Experience, 26(10), Conducted at Ericsson s PMR project Example of successful project Method and tool: Forward engineering, Objectory SE (forerunner of UML and IBM Rational Updating of models was emphasised by the project leader Object-to-object traceability Task: trace the concept Connection as described in the RS: The purpose is to provide a PMR operator with a presentation of the output from the recording in such a way that support is given for troubleshooting, verification of the radio network during one or several Connections for a specified MS 11

12 Original model Association-to-association traceability Task: determine if there is a correspondence between associations of the objects Correct and simplified model 12

13 Are these the same models? Use-case to object traceability Task: trace the requirement Recording Collection. Step 1: Find the use-case with name tracing Step 2: Trace to analysis objects Step 3: Trace to design objects via use-case Finally: Compare the object models Use-case to object traceability 13

14 Three-to-one traceability Many-to-many traceability Two-dimensional traceability 14

15 A wicked visualisation problem Requirements Design Application: Impact analysis Lindvall Lindvall & Sandahl: Sandahl: Case-study Case-study PMR: PMR: Underprediction factor factor 1,5 1, predicted actual unnecessary correct wrong Matrix browser 15

16 Table lens Future: Automated component procurement Architecture search Vendors C3 C1 negotiate buy C2 deliver Semantic-rich specifications make traceability dynamic. Future: Integrational Software Engineering R1 R2 R3 R4 C1 Final system C2 Op2 Op3 C3 Op1 Op5 A1 Conclusions Traceability in model-based development is possible and boosts system understanding and correctness In practice many different methods are used simultaneously You need to determine what is important to trace Sometimes you can get traceability for free To take full advantage you need to invest and handle the attitudes 16

17 Introduction Just as models, formal methods is a complement to other specification methods. Standard is model-based methods, specified mathematically and interpreted with logic. Benefits: Non-ambiguous specification, all issues are discovered, proof of properties, simulation, code generation. Costs: Time, tools, training and inherent complexity of algorithms. High costs use only for critical applications The three Cs - definition Consistency no internal contradictions Completeness everything is there Correctness satisfaction of business goals Potential problems: adding requirements make the specification more complete, but there is a risk of introducing contradiction. correctness is vaguely defined, formally: consistent + complete? pragmatically: satisfaction of customer needs? Content Formal specifications in an evolutionary context. Based on: Zowghi, D. and Gervasi, V. (2002) The three Cs of Requirements: Consistency, Completeness and Correctness, Proc. of the 8 th Int. Workshop on Requirements Engineering: Foundation for Software Quality. Essen, Germany, September 9-10, 2002, pp Example in Z Single specification model Requirements Specification states relationships between elements of Domain provides an interface to S D R What we know about the domain, system and interfaces makes R true. Nothing in R is missing in S and D S D is consistent mission of S is possible Tells if S is complete with respect to R Proof obligation towards correctness of S,or formal proof of correctness? 17

18 Evolutionary model change change change B R 1 R 2 S monotonic change monotonic change D 1 D 2 D 3 Business goal or Belief To make notation more convenient, let B = R 0 and S = R n+1 Example: shop owner(1) B = {when a customer comes near the entrance, the door shall open} First attempt: D 1 = {when a person comes near the entrance door, a presence sensor gets activated} R 1 = {when the sensor gets activated, the door shall open} Prove R 1 D 1 B, and fail, since B talks about customers, D 1 talks about persons Two choices: Improve D 1 with biometry and recognition or weaken B: B = {when a person comes near the entrance, the door shall open} Prove R 1 D 1 B and succeed (consistent, complete) The three Cs R 0 R 1 R 2 R n+1 D 1 D 2 D 3 R i D i R i-1 Induction gives: (completeness) R n+1 D n+1 R 0 { } R i D i (consistency) Replace back and have: D i D i-1 (monotonicity) S D R i D i R i-1 D n+1 B i-1 Specification deployed in final domain satisfies customer needs = correctness Example: shop owner (2) Second iteration: D 2 = D 1 {when a sliding door s motor is turned on, the door opens} R 2 = {when the sensor gets activated, the door s motor shall be turned on} R 2 D 2 is consistent and complete w.r.t R 1 D 2 D 1 (containment) R 2 R 1 (knowledge about whether motor(on) door(opened) is the the domain theory, not in Rs) Continued development: S = {when a signal is detected on the input line associated with the door s presence sensor, establish +5V on the output line associated with the door s motor} If we have proved consistency and completeness in all iterations, S is correct w.r.t B 18

19 Z example The NFR Framework (cont d) Example: Design of system for managing credit card account How frequently update account info? How identify customers? Where to store data? The NFR Framework Chung et al: Non-Functional Requirements in Software Engineering Based on PhD work A structured way of decomposing NFRs Goal-Oriented Requirements Engineering: KAOS i* The NFR Framework (cont d) A process-oriented way of representing and analysing NFRs Concepts Softgoals: A goal that has no clear-cut definition and/or criteria as to whether it is satisfied or not. Satisficed: being sufficiently satisfactory Softgoal Interdependency Graphs Catalogues 19