SOFTWARE ENGINEERING REQUIREMENTS ANALYSIS AND SPECIFICATION. Saulius Ragaišis.

Transcription

1 SOFTWARE ENGINEERING REQUIREMENTS ANALYSIS AND SPECIFICATION Saulius Ragaišis

2 CSC2008 SE Requirements Specifications Learning Objectives: Apply key elements and common methods for elicitation and analysis to produce a set of software requirements for a mediumsized software system. Discuss the challenges of maintaining legacy software. Use a common, non-formal method to model and specify (in the form of a requirements specification document) the requirements for a medium-size software system. Conduct a review of a software requirements document using best practices to determine the quality of the document. Translate into natural language a software requirements specification (e.g., a software component contract) written in a formal specification language.

3 SYSTEM ENGINEERING

4 Definition A computer-based system is a set or arrangement of elements that are organized to accomplish some predefined goal by processing information.

5 System elements Software Hardware People Procedures Database Documentation

6 System modeling Define the processes that serve the needs of the view under consideration. Represent behavior of the processes and the assumptions on which the behavior is based. Explicitly define both exogenous and endogenous input to the model. Represent all linkages (including output) that will enable the engineer to better understand the view.

7 Restraining factors Assumptions Simplifications Limitations Constraints Preferences

8 Business process engineering A goal of BPE is to define architectures that will enable a business to use information effectively. The architectures must be analyzed and designed within the context of business objectives and goals: Data architecture Applications architecture Technology infrastructure

9 Product engineering The goal of product engineering is to translate the customer s desire for a set of defined capabilities into a working product. To achieve this goal product engineering should derive: architecture encompasses 4 distinct system components: software, hardware, data (and databases), and people; infrastructure is established and includes the technology required to tie the components together and the information (e.g., documents) that is used to support the components.

10 Interesting reading Cathleen Shamieh Systems Engineering For Dummies, IBM Limited Edition Wiley Publishing, Inc., available for download

11 SOFTWARE REQUIREMENTS ENGINEERING

12 What is it? Requirements engineering helps software engineers to better understand the problem they will work to solve. It encompasses the set of tasks that lead to an understanding of: what the business impact of the software will be, what the customer wants, and how end-users will interact with the software.

13 What are the steps? Inception - a task that defines the scope and nature of the problem to be solved Elicitation - a task that helps the customer to define what is required Elaboration - where basic requirements are refined and modified Negotiation - what are the priorities, what is essential, when it is required Specification Validation Management

14 What is the work product? The intent of the requirements engineering process is to provide all parties with a written understanding of the problem. This can be achieved though a number of work products: user scenarios, functions and features lists, analysis models, or specification.

15 Initiating RE process Identifying the stakeholders Recognizing multiple viewpoints Working towards collaboration Asking the first questions

16 Requirements elicitation Standish Group listed Lack of User Input as most common factor of challenged projects. Requirements Elicitation is the process of discovering the requirements for a system by communication with customers, system users and other stakeholders. Development teams have to take the initiative.

17 Difficulties in requirements elicitation Problems of scope. Problems of understanding. Problems of volatility.

18 Challenges of requirements elicitation Yes, But syndrome Undiscovered Ruins syndrome User and Developer syndrome The sins of your predecessors syndrome

19 Yes, But syndrome First time users see the system the first reaction is either, wow this is so cool or Yes, but, hm, now that I see it, what about this? Wouldn t it be nice? Users reaction is simply human nature. Need to employ techniques that get the yes, buts out early. Anticipate that there will be yes, buts and add time and resources to plan for feedback. Tends to be user interface centric, these tend to be the touch points of the system by the users.

20 Undiscovered Ruins syndrome Teams struggle with determining when they are done with requirements elicitation. Is done when all the requirements are elicited or have they found at least enough? Like asking an archeologist how many undiscovered ruins are there? First scope the requirements elicitation effort by defining the problem or problems that are to be solved with the system. Employ techniques that help find some of those ruins and have the stakeholders buy-into the requirements.

21 User and the Developer syndrome Characteristic Users do not know what they want, or they know what they want but cannot articulate it. Users think they know what they want until developers give them what they said they wanted. Analysts think they understand user problems better than users do. Everybody believes everybody else is politically motivated. Response Recognize and appreciate the user as domain experts; try different techniques. Provide alternative elicitation techniques earlier; storyboard, role playing, prototypes, and so on. Put the analyst in the users place. Try role playing for an hour or a day. Yes, its part of human nature, so lets get on with the program.

22 The sins of your predecessors syndrome Like it or not your users (marketing) and developers remember what happened in the past. Quality programs that promised things would be different. The last project where requirements were vague and/or were delivered short of expectations. The team unilaterally cut important features out of the last release. Need to build trust, slowly. Do not over commit to features, schedule, or budget. Build success by delivering highest priority features early in the process.

23 Requirements elicitation guidelines Assess system feasibility Be sensitive to organizational and political considerations Identify and consult system stakeholders Record requirements sources Use business concerns to drive requirements elicitation Look for domain constraints Record requirements rationale Collect requirements from multiple viewpoints Prototype poorly understood requirements Use scenarios to elicit requirements Define operational processes Reuse requirements

24 Requirements elicitation techniques Interviewing and questionnaires Requirements workshops Braining storming and idea reduction Storyboards Use cases Role playing Prototyping

25 Interviewing Simple direct technique Context-free questions can help achieve bias-free interviews Then, it may be appropriate to search for undiscovered requirements by exploring solutions. Convergence on some common needs will initiate a requirements repository for use during the project. A questionnaire is no substitute for an interview.

26 Requirements workshop The requirements workshop is perhaps the most powerful technique for eliciting requirements. It gathers all key stakeholders together for a short but intensely focused period. The use of an outside facilitator experienced in requirements management can ensure the success of the workshop. Brainstorming is the most important part of the workshop.

27 Brainstorming Brainstorming involves both idea generation and idea reduction. The most creative, innovative ideas often result from combining, seemingly unrelated ideas. Various voting techniques may be used to prioritize the ideas created. Although live brainstorming is preferred, webbased brainstorming may be a viable alternative in some situations

28 Brainstorming (2) Do not allow criticism or debate. Let your imagination soar Generate as many ideas as possible Mutate and combine ideas Idea Reduction Pruning ideas that are not worthy of further discussion Grouping of similar ideas into one super topic Prioritize the remaining ideas

29 Storyboarding The purpose of storyboarding is to elicit early Yes, But reactions. Storyboards can be positive, active, or inactive. Storyboards identify the players, explain what happens to them, and describes how it happens. Make the storyboard sketchy, easy to modify, and unshippable. Storyboard early and often on every project with new or innovative content.

30 Use cases Use cases, like storyboards, identify the who, what, and how of system behavior. Use cases describe the interactions between a user and a system, focusing on what the system does for the user. The use case model describes the totality of the systems functional behavior. Early stages: After you have an overview of the use cases, perhaps only by a phrase apiece, expand 10% of them in detail. Weakness of use cases -- we miss the quality attributes.

31 Prototyping Prototyping is especially effective in addressing the Yes, But and the Undiscovered Ruins syndromes. A software requirements prototype is a partial implementation of a software system, built to help developers, users, and customers better understand system requirements. Prototype the fuzzy requirements: those that, although known or implied, are poorly defined and poorly understood.

32 Functional and non-functional requirements IEEE definitions: Functional requirement - a requirement that specifies a function that a system/software system or its component must be capable of performing. These are software requirements that define behavior of the system, that is, the fundamental process or transformation that software and hardware components of the system perform on inputs to produce outputs. Nonfunctional requirement - a software requirement that describes not what the software will do, but how the software will do it, for example, software performance requirements, software external interface requirements, software design constraints, and software quality attributes. Nonfunctional requirements are difficult to test; therefore, they are usually evaluated subjectively.

33 Other definitions Functional requirement (FR) defines a function of a software system or its component. A function is described as a set of inputs, the behavior, and outputs. FR may be calculations, technical details, data manipulation and processing and other specific functionality that define what a system is supposed to accomplish. Non-functional requirement (NFR) is a requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Other terms for NFR are "constraints", "quality attributes", "quality goals", "quality of service requirements" and "non-behavioral requirements".

34 Uncertainty Principle in SE Uncertainty is inherent and inevitable in software development processes and products.

35 Causes of uncertainty in requirements Incomplete knowledge Imprecise understanding of needs Differing needs among users Changing needs

36 REQUIREMENTS ANALYSIS MODELING TECHNIQUES

37 Requirements analysis (RA) RA results in the specification of software s operational characteristics; indicates software s interface with other system elements; and establishes constraints that software must meet. RA provides the software designer with representation of information function, and behavior that can be translated to architectural, interface, and component level design. The analysis model and the requirements specification provide the developer and the customer with the means to asses quality once software is built.

38 Analysis rules of thumb The model should focus on requirements that are visible within the problem and business domain. The level of abstraction should be relatively high. Each element of the analysis model should add to an overall understanding of software requirements and provide insight into the information domain, function, and behavior of the system.

39 Analysis rules of thumb (2) Delay consideration of infrastructure and other non-functional models until design. Minimize coupling throughout the system. Be certain that the analysis model provides value to all stakeholders. Keep the model as simple as it can be.

40 Domain analysis

41 Analysis modeling approaches Structured analysis considers data and the processes that transform the data as separate entities. Object-oriented analysis focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements.

42 Elements of the analysis model Scenario-based elements: use-cases - text, use-case diagrams, activity diagrams, swim lane diagrams. Class-based elements: class diagrams, analysis packages, CRC models, collaboration diagrams. Behavioral elements: state diagrams, sequence diagrams. Flow-oriented elements: data flow diagrams, control flow diagrams, processing narratives.

43 Data modeling concepts Data objects Data attributes Relationships Cardinality and modality

44 Flow-oriented modeling The level 0 data flow (context) diagram should depict the software/system as a single bubble. Primary input and output should be carefully noted. Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level. All arrows and bubbles should be labeled with meaningful names. Information flow continuity must be maintained from level to level. One bubble at a time should be refined.

45 Context DFD (example)

46 Level 1 DFD (example)

47 Other flow-oriented elements Control flow modeling Control specification (CSPEC) Process specification (PSPEC)

48 FORMAL SPECIFICATION TECHNIQUES

49 Formal methods Advantages Disadvantages

50 Definition A method is formal if it has a sound mathematical basis, typically given by a formal specification language. This basis provides a means of precisely defining notions like consistency and completeness, and more relevantly, specification, implementation and correctness. [The Encyclopedia of Software Engineering]

51 Mathematical Fundamentals Relations, Functions, Logical expressions, Quantifiers, Types, Sequences, Tuples, Propositional Logic, Sets, First-Order Logic, and etc.

52 Example: a block handler Block handler is a part of the file system. Files are composed of blocks. Files will be created and deleted. The system should maintain unused (free) blocks and keep track of blocks in use. When blocks of deleted file are released, they are added to a queue of blocks waiting to be added to the reservoir of unused blocks. State of block handler consists of the collection of free blocks, the collection of used blocks, and the queue of returned blocks.

53 Example: a block handler (2) Data invariant is: No block is marked as both used and unused. All the sets of blocks in the queue are subsets of the collection of used blocks. No elements of the queue contain the same block. The collection of used and unused blocks is the total collection of blocks. The collection of unused blocks have no duplicates. The collection of used blocks have no duplicates.

54 Example: a block handler (3) Operations: add() a collection of blocks to the end of the queue; remove() a collection of used blocks from the front of the queue and place them in the collection of unused blocks; check() whether the queue of blocks is empty.

55 Z specification language Z is a model-based specification framework. The idea is to construct an abstract model of the system to be built. It is high level, idealized, does not detail with implementation specifics. The model consists of descriptions of system state space and system operations. State space is the set of all states that the system could be. The state describes the value of each variable (and memory location).

56 Z schemas Z schema is a 2-dimensional graphical notation for describing state spaces and operations. A vertical-form schema is either of the form SchemaName Declarations Predicate 1 ; ; Predicaten or of the form SchemaName Declarations

57 Other Z notations Sets: S : P X S is declared as a set of X S. x S x is a member of S. x S x is not a member of S. S T S is a subset of T: Every member of S is also in T. S T The union of S and T: It contains every member of S or T or both. S T The intersection of S and T: It contains every member of both S and T. S \ T The difference of S and T: It contains every member of S except those also in T. Ø Empty set: It contains no members. {x} Singleton set: It contains just x. N The set of natural numbers 0, 1, 2, S: F X S is declared as a finite set of X S. max (S) The maximum of the nonempty set of numbers S. Functions: f:x Y f is declared as a partial injection from X to Y. dom f The domain of f: the set of values x for which f(x) is defined. ran f The range of f: the set of values taken by f(x) as x varies over the domain of f. f {x y} A function that agrees with f except that x is mapped to y. {x} f A function like f, except that x is removed from its domain. Logic: P Λ Q P Q θ S' = θ S P and Q: It is true if both P and Q are true. P implies Q: It is true if either Q is true or P is false. No components of schema S change in an operation.

58 Example using Z State of block handler and data invariant: BlockHandler used, free : P BLOCKS BlockQueue : seq P BLOCKS used free = Ø Λ used free = AllBlocks Λ i : dom BlockQueue BlockQueue i used Λ i, j : dom BlockQueue i j => BlockQueue i BlockQueue j = Ø

59 Example using Z: operations RemoveBlocks BlockHandler # BlockQueue >0, used' = used \ head BlockQueue Λ free' = free BlockQueue Λ BlockQueue ' = tail BlockQueue AddBlocks BlockHandler Ablocks? : BLOCKS Ablocks? used BlockQueue' = BlockQueue. Ablocks? Λ used' = used Λ free' = free

60 Object Constraint Language (OCL) OCL is a formal notation used in UML diagrams for more precise specification of their elements. OCL expressions are called constraints; implementation should ensure that constraints always remains true. Expressions involve operators on operating objects but their result is Boolean. The object self is the element of UML diagram in the context of which OCL expression is being evaluated.

61 Key OCL notations OCL notation x.y c >f() and, or, = <> p implies q Meaning Obtain the property y of object x. A property can be an attribute, the set of objects at the end of an association, the result of evaluating an operation, or other things depending on the type of UML diagram. If x is a Set, then y is applied to every element of x; the results are collected into a new Set. Apply the built-in OCL operation f to Collection c itself (as opposed to each of the objects in c). Examples of built-in operations are listed below. Logical and, logical or, equals, not-equals. True if either q is true or p is false. Sample of Operations Specific to Sets s1 >intersection(s2) s1 >union(s2) s1 >excluding(x) The set of those elements found in s1 and also in s2. The set of those elements found in either s1 or s2. The set s1 with object x omitted.

62 Key OCL notations (2) Sample of Operations on Collections (including Sets and Sequences) c >size() The number of elements in Collection c. c >isempty() True if c has no elements, false otherwise. c1 >includesall(c2) True if every element of c2 is found in c1. c1 >excludesall(c2) True if no element of c2 is found in c1. c >forall(elem boolexpr) True if boolexpr is true when applied to every element of c. As an element is being evaluated, it is bound to the variable elem, which can be used in boolexpr. This implements universal quantification, discussed earlier. c >forall(elem1, elem2 boolexpr) Same as above, except that boolexpr is evaluated for every possible pair of elements taken from c, including cases where the pair consists of the same element. c >isunique(elem expr) True if expr evaluates to a different value when applied to every element of c. Sample Operation Specific to Sequences seq >first() The object that is the first element in the sequence seq.

63 Example using OCL No block will be marked as both used and unused: context BlockHandler inv: (self.used -> intersection(self.free)) -> isempty() All the sets of blocks in the queue are subsets of the collection of used blocks: context BlockHandler inv: blockqueue -> forall(ablockset used -> includesall)ablockset)) No elements of the queue contain the same block context BlockHandler inv: blockqueue -> forall(blockset1, blockset2 blockset1 <> blockset2 implies blockset1.elements.number -> excludesall(blockset1.elements.number))

64 SOFTWARE COMPONENT CONTRACT

65 Contract Contract is a collection of assertions that describe precisely what each feature of the component does and does not do. Levels of contract: 1. Basic, or syntactic, contracts are required simply to make the system work. 2. Behavioral contracts improve the level of confidence in a sequential context. 3. Synchronization contracts improve the level of confidence in distributed or concurrency context. 4. Quality-of-service contracts quantify quality of service and is usually negotiable.

66 Basic contracts Interface definition language (IDL), as well as typed object-based or object-oriented languages, let specify: the operations a component can perform, the input and output parameters each component requires, and the possible exceptions that might be raised during operation.

67 Behavioral contracts First implemented under the name design by contract in the Eiffel language. Also they can be found in UML as the Object Constraint Language (OCL). The key assertions in the design by contract technique are of three types: invariants, preconditions, and postconditions.

68 Invariant Invariant is a constraint attached to type that must be held true for all instances of the type whenever an operation is not being performed on the instance. For example, an invariant might state that the value of some attribute is always greater than zero. In the case of component methods, the invariants can be attached to an interface to specify properties of the component objects that implement the interface.

69 Preconditions and postconditions Preconditions and postconditions are assertions attached to an operation of a type. Precondition expresses requirements that any call of the operation must satisfy if it is to be correct. Postcondition expresses properties that are ensured in return by the execution of the call. For example, an operation to delete a record from a collection might have a precondition requiring that a record with that key exists and a postcondition requiring that it no longer be an element of the collection.

70 Synchronization contracts The aim of such contract is to describe the dependencies between services provided by a component, such as sequence, parallelism, or shuffle. They could be expressed by attaching to components special elements called synchronization policies. Java provides a stripped-down version of synchronization through the keyword synchronized.

71 Quality-of-service contracts Common examples: maximum response delay; average response; quality of the result, expressed as precision; result throughput for multiobject answers such as data streams.

72 What we have learned? Main concepts of requirements analysis and specification Overview of structured analysis and formal methods Next (more detailed) Object-oriented analysis

73 QUESTIONS?