Lecture 6: Requirements Engineering

Transcription

1 Lecture 6: Requirements Engineering Software System Design and Implementation ITCS/ITIS 6112/ Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Sept. 11, 2008

2 Classification of Requirements Functional vs. non-functional domain User vs. System 2

3 Goals vs. Non-functional Requirements Difficult to state non-functional requirements precisely Imprecise requirements are difficult to verify! May result in expression of a goal A general intention of the user e.g., ease of use, reasonable performance, maintainability Want verifiable non-functional requirements Using some measure that can be objectively tested Quantifiable! Goals can help convey the intentions of the system users Should warn user that difficult to validate 3

4 Examples A system goal The system should be easy to use by experienced air traffic controllers and should be organized in such a way that user errors are minimized. A verifiable non-functional requirement Experienced air traffic controllers shall be able to use all the system functions after a total of two hours training; after this training, the average number of errors made by experienced users shall not exceed two per day. 4

5 Turning Goals into Requirements: System Property Metrics Property Speed Size Ease of use Reliability Robustness Portability Measure Processed transactions/second User/Event response time Screen refresh time M Bytes Number of ROM chips Training time Number of help frames Mean time to failure Probability of unavailability Rate of failure occurrence Availability Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Percentage of target dependent statements Number of target systems 5

6 Non-functional Requirements Interaction Conflicts between different non-functional requirements are common Spacecraft system To minimize weight, the number of separate chips in the system should be minimized. To minimize power consumption, lower power chips should be used. Conflict! Why? Which is most critical? 6

7 Domain Requirements Describe system characteristics and features that reflect application domain May be new functional or non-functional requirements May be constraints on existing requirements May define specific computations If domain requirements are not satisfied, the system may be unworkable! Why do we separate these kinds of requirements out? Reuse! 7

8 Domain Requirements Example: Train Protection System The deceleration of the train shall be computed as: D train = D control + D gradient where D gradient = 9.81m/s 2 * compensated gradient/alpha and where the values of 9.81ms 2 /alpha are known for different types of trains. 8

9 Domain Requirements Issues Understandability Requirements expressed in language of the application domain (jargon) Not understood by software engineers developing the system Implicitness Domain specialists do not make domain requirements explicit 9

10 Classification of Requirements Functional vs. non-functional User vs. System 10

11 User Requirements Describe both functional and non-functional requirements in a way understandable to system users Example The software must provide a means of representing and accessing external files created by other tools 11

12 System Requirements More detailed specifications of system functions services constraints Intended as basis for designing the system Example The user should be provided with facilities to define the type of external file Each external file type may have an associated tool which may be applied to the file Each external file type may be represented as a specific icon When a user selects an icon representing an external file, the effect is to apply the tool associated with the type of external file to the file represented by the selected icon 12

13 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 13

14 Inception Goal is to develop a very basic understanding of: Problem People that want a solution Nature of desired solution Effectiveness of initial communication between customer and developer Results in Statement of business need for software to be developed Feasibility of developing software 14

15 Inception Actions Identify stakeholders Anyone that benefits from system to be developed Typical examples Marketing Customer End-user Software engineers Identify and organize viewpoints Further classify stakeholders according to perspectives Broadly: Interactor Indirect Domain 15

16 Viewpoint Example Interactor Indirect Domain Library manager Finance Publishers User Faculty Student Library staff Classification standards Copyright regulations 16

17 Inception Actions (2) Ask context-free questions: Regarding stakeholders Who requested this system? Who will use it? What is the economic benefit? Is there another source for the desired solution? Regarding the problem What would be good output generated by the solution? What problem does the solution address? What kind of business environment will this be used in? Are there performance issues or constraints? 17

18 Inception Actions (3) Ask context-free questions: Regarding communication Are you the right person to answer these questions? Is this answer official? Are my questions relevant? Can anyone else provide additional information? Should I be asking you anything else? 18

19 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 19

20 Elicitation Goal is to understand the system that is to be developed More specific information is elicited from the stakeholders Approaches to elicitation Research Observation Documentation studies Comparative product studies Guided Meetings Interview Focus groups Elicitation workshops Prototype demonstrations Scenarios and Use Cases More detailed and pointed questions May propose some services, features 20

21 Scenarios Real-life examples of how a system can be used They should include A description of the involved stakeholders A description of the starting situation A description of the normal flow of events A description of what can go wrong Information about other concurrent activities A description of the state when the scenario finishes 21

22 Scenario Example Ask the SafeHome user: How would you use the home security function? 22

23 Use Cases Scenario-based descriptions of how an actor interacts with the system Actor (UML terminology) Represents role people or device play when using the system External to system (system is not an actor) Captures functional requirements Captures functional requirements Abstraction of a scenario A scenario is one specific path Use case captures multiple related paths of interaction Serve as basis for developing more detailed models Supports traceability of requirements and design 23

24 Capturing Use Cases Two forms of use case specification Full textual description Name Actors Preconditions Trigger Scenario Description Exceptions (a.k.a. Extensions) Postconditions Associated non-functional requirements (optional) UML graphical description We ll see this later 24

25 Use Case Example Ask the SafeHome user: How would you use the home security function? 25

26 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 26

27 Elaboration/Analysis Refine models of requirements Organize requirements according to: Stakeholders Viewpoints Service Preliminary decomposition of the system Prioritize requirements (and risks) Update cost estimates Negotiate requirements Customers may ask for more than can be achieved Prioritization information may be in conflict 27

28 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 28

29 Approaches to Specifying Requirements Structured natural language Rules guide specification of requirements Graphical modeling notations Easy to understand graphical representations Mathematical specifications Based on mathematical concepts such as sets or finite state machines 29

30 Problems with Natural Language Ambiguity Readers and writers of the requirement must interpret the same words in the same way Over-flexibility The same thing may be said in a number of different ways Lack of modularization Natural language structures doesn t capture hierarchical requirement relationships 30

31 Guidelines for Using Structured Natural Language Rules for writing user and system requirements: Use standard structured format Write complete, simple sentences Use active voice Define terms, use them consistently Group related requirements hierarchically Express all requirements using must or shall Write requirements in a verifiable manner Write atomic requirements States a single product function, feature, or characteristic Helps with requirements traceability 31

32 Structured Natural Language for Scenarios Rules for writing scenarios: All of the previous rules Format: Initial assumption Normal execution Exceptional execution State on completion 32

33 Structured Natural Language for Use Cases Rules for writing scenarios: All of the previous natural language rules Format: Use-Case Name Actors Pre-conditions Post-conditions Trigger Basic Flow Extensions Non-functional Requirements 33

34 Use Cases with UML Basic Notation Bank Customer Withdraw Money More on use cases and UML use case notation coming soon 34

35 Requirements Engineering Activities Inception Elicitation Elaboration/Analysis Negotiation Specification Validation 35