Lecture 4 Software Requirements Analysis II PDF

Lecture 4 Software Requirements Analysis II Requirements Modeling: Class-Based Methods These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 1 Require...

Lecture 4 Software Requirements Analysis II Requirements Modeling: Class-Based Methods These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 1 Requirements Modeling Strategies One view of requirements modeling, called structured analysis, considers data and the processes that transform the data as separate entities. Data objects are modeled in a way that defines their attributes and relationships. Processes that manipulate data objects are modeled in a manner that shows how they transform data as data objects flow through the system. A second approach to analysis modeled, called object- oriented analysis, focuses on the definition of classes and the manner in which they collaborate with one another to effect customer requirements. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 2 Class-Based Modeling Class-based modeling represents: objects that the system will manipulate operations (also called methods or services) that will be applied to the objects to effect the manipulation relationships (some hierarchical) between the objects collaborations that occur between the classes that are defined. The elements of a class-based model include classes and objects, attributes, operations, CRC models, collaboration diagrams and packages. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 3 Identifying Analysis Classes Examining the usage scenarios developed as part of the requirements model and perform a "grammatical parse" [Abb83] Classes are determined by underlining each noun or noun phrase and entering it into a simple table. Synonyms should be noted. If the class (noun) is required to implement a solution, then it is part of the solution space; otherwise, if a class is necessary only to describe a solution, it is part of the problem space. But what should we look for once all of the nouns have been isolated? These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 4 Manifestations of Analysis Classes Analysis classes manifest themselves in one of the following ways: External entities (e.g., other systems, devices, people) that produce or consume information Things (e.g, reports, displays, letters, signals) that are part of the information domain for the problem Occurrences or events (e.g., a property transfer or the completion of a series of robot movements) that occur within the context of system operation Roles (e.g., manager, engineer, salesperson) played by people who interact with the system Organizational units (e.g., division, group, team) that are relevant to an application Places (e.g., manufacturing floor or loading dock) that establish the context of the problem and the overall function Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class of objects or related classes of objects These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 5 Potential Classes Retained information. The potential class will be useful during analysis only if information about it must be remembered so that the system can function. Needed services. The potential class must have a set of identifiable operations that can change the value of its attributes in some way. Multiple attributes. During requirement analysis, the focus should be on "major" information; a class with a single attribute may, in fact, be useful during design, but is probably better represented as an attribute of another class during the analysis activity. Common attributes. A set of attributes can be defined for the potential class and these attributes apply to all instances of the class. Common operations. A set of operations can be defined for the potential class and these operations apply to all instances of the class. Essential requirements. External entities that appear in the problem space and produce or consume information essential to the operation of any solution for the system will almost always be defined as classes in the requirements model. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 6 Defining Attributes Attributes describe a class that has been selected for inclusion in the analysis model. build two different classes for professional baseball players For Playing Statistics software: name, position, batting average, fielding percentage, years played, and games played might be relevant For Pension Fund software: average salary, credit toward full vesting, pension plan options chosen, mailing address, and the like. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 7 Defining Operations Do a grammatical parse of a processing narrative and look at the verbs Operations can be divided into four broad categories: (1) operations that manipulate data in some way (e.g., adding, deleting, reformatting, selecting) (2) operations that perform a computation (3) operations that inquire about the state of an object, and (4) operations that monitor an object for the occurrence of a controlling event. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 8 CRC Models Class-responsibility-collaborator (CRC) modeling [Wir90] provides a simple means for identifying and organizing the classes that are relevant to system or product requirements. Ambler [Amb95] describes CRC modeling in the following way: A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the class. In the body of the card you list the class responsibilities on the left and the collaborators on the right. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 9 CRC Modeling Class: Class: Description: Class: Description: Class:FloorPlan Description: Responsibility: Description: Collaborator: Responsibility: Collaborator: Responsibility: Collaborator: Responsibility: Collaborator: defines floor plan name/type manages floor plan positioning scales floor plan for display scales floor plan for display incorporates walls, doors and windows Wall shows position of video cameras Camera These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 10 Class Types Entity classes, also called model or business classes, are extracted directly from the statement of the problem (e.g., FloorPlan and Sensor). Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used. Controller classes manage a “unit of work” [UML03] from start to finish. That is, controller classes can be designed to manage the creation or update of entity objects; the instantiation of boundary objects as they obtain information from entity objects; complex communication between sets of objects; validation of data communicated between objects or between the user and the application. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 11 Responsibilities System intelligence should be distributed across classes to best address the needs of the problem Each responsibility should be stated as generally as possible Information and the behavior related to it should reside within the same class Information about one thing should be localized with a single class, not distributed across multiple classes. Responsibilities should be shared among related classes, when appropriate. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 12 Collaborations Classes fulfill their responsibilities in one of two ways: A class can use its own operations to manipulate its own attributes, thereby fulfilling a particular responsibility, or a class can collaborate with other classes. Collaborations identify relationships between classes Collaborations are identified by determining whether a class can fulfill each responsibility itself three different generic relationships between classes [WIR90]: the is-part-of relationship the has-knowledge-of relationship the depends-upon relationship These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 13 Composite Aggregate Class Player PlayerHead PlayerBody PlayerArms PlayerLegs These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 14 Reviewing the CRC Model All participants in the review (of the CRC model) are given a subset of the CRC model index cards. Cards that collaborate should be separated (i.e., no reviewer should have two cards that collaborate). All use-case scenarios (and corresponding use-case diagrams) should be organized into categories. The review leader reads the use-case deliberately. As the review leader comes to a named object, she passes a token to the person holding the corresponding class index card. When the token is passed, the holder of the class card is asked to describe the responsibilities noted on the card. The group determines whether one (or more) of the responsibilities satisfies the use-case requirement. If the responsibilities and collaborations noted on the index cards cannot accommodate the use-case, modifications are made to the cards. This may include the definition of new classes (and corresponding CRC index cards) or the specification of new or revised responsibilities or collaborations on existing cards. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 15 Associations and Dependencies Two analysis classes are often related to one another in some fashion In UML these relationships are called associations Associations can be refined by indicating multiplicity (the term cardinality is used in data modeling In many instances, a client-server relationship exists between two analysis classes. In such cases, a client-class depends on the server- class in some way and a dependency relationship is established These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 16 Multiplicity Wall 1 1 1 is used to build is used to build 1..* 0..* is used to build 0..* WallSegment Window Door These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 17 Dependencies DisplayWindow Camera {password} These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 18 Analysis Packages Various elements of the analysis model (e.g., use-cases, analysis classes) are categorized in a manner that packages them as a grouping The plus sign preceding the analysis class name in each package indicates that the classes have public visibility and are therefore accessible from other packages. Other symbols can precede an element within a package. A minus sign indicates that an element is hidden from all other packages and a # symbol indicates that an element is accessible only to packages contained within a given package. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 19 Analysis Packages package name Environment +Tree +Landscape +Road +Wall +Bridge +Building RulesOfTheGame +VisualEffect +Scene +RulesOfMovement +ConstraintsOnAction Characters +Player +Protagonist +Antagonist +SupportingRole These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 20  Requirements Modeling: Behavior, Patterns, and Web/Mobile Apps Behavioral Modeling The behavioral model indicates how software will respond to external events or stimuli. To create the model, the analyst must perform the following steps: Evaluate all use-cases to fully understand the sequence of interaction within the system. Identify events that drive the interaction sequence and understand how these events relate to specific objects. Create a sequence for each use-case. Build a state diagram for the system. Review the behavioral model to verify accuracy and consistency. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill, 2014). Slides copyright 2014 by Roger Pressman. 21  State Representations In the context of behavioral modeling, two different characterizations of states must be considered: the state of each class as the system performs its function and the state of the system as observed from the outside as the system performs its function The state of a class takes on both passive and active characteristics [CHA93]. A passive state is simply the current status of all of an object’s attributes. The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 22 State Diagram for the ControlPanel Class t imer < lockedTime t imer > lockedTime locked password = incorrect & numberOfTries < maxTries reading comparing numberOfTries > maxTries key hit password ent ered do: validat ePassword password = correct select ing act ivat ion successful These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 23 The States of a System state—a set of observable circum- stances that characterizes the behavior of a system at a given time state transition—the movement from one state to another event—an occurrence that causes the system to exhibit some predictable form of behavior action—process that occurs as a consequence of making a transition These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 24  Behavioral Modeling make a list of the different states of a system (How does the system behave?) indicate how the system makes a transition from one state to another (How does the system change state?) indicate event indicate action draw a state diagram or a sequence diagram These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 25  Sequence Diagram homeowner cont rol panel syst em sensors sensors syst em reading A ready password ent ered request lookup comparing result password = correct numberOfTries > maxTries request act ivat ion locked t imer > lockedTime A select ing act ivat ion successful act ivat ion successful Figure 8.27 Sequence diagram (part ial) f or Saf eHome securit y f unct ion These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 26 Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down! These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 27 Patterns for Requirements Modeling Software patterns are a mechanism for capturing domain knowledge in a way that allows it to be reapplied when a new problem is encountered domain knowledge can be applied to a new problem within the same application domain the domain knowledge captured by a pattern can be applied by analogy to a completely different application domain. The original author of an analysis pattern does not “create” the pattern, but rather, discovers it as requirements engineering work is being conducted. Once the pattern has been discovered, it is documented These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 28 Discovering Analysis Patterns The most basic element in the description of a requirements model is the use case. A coherent set of use cases may serve as the basis for discovering one or more analysis patterns. A semantic analysis pattern (SAP) “is a pattern that describes a small set of coherent use cases that together describe a basic generic application.” [Fer00] These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 29 Requirements Modeling for WebApps Content Analysis. The full spectrum of content to be provided by the WebApp is identified, including text, graphics and images, video, and audio data. Data modeling can be used to identify and describe each of the data objects. Interaction Analysis. The manner in which the user interacts with the WebApp is described in detail. Use-cases can be developed to provide detailed descriptions of this interaction. Functional Analysis. The usage scenarios (use-cases) created as part of interaction analysis define the operations that will be applied to WebApp content and imply other processing functions. All operations and functions are described in detail. Configuration Analysis. The environment and infrastructure in which the WebApp resides are described in detail. These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 30 When Do We Perform Analysis? In some Web/Mobile App situations, analysis and design merge. However, an explicit analysis activity occurs when … the Web or Mobile App to be built is large and/or complex the number of stakeholders is large the number of developers is large the development team members have not worked together before the success of the app will have a strong bearing on the success of the business These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 31 The Content Model Content objects are extracted from use-cases examine the scenario description for direct and indirect references to content Attributes of each content object are identified The relationships among content objects and/or the hierarchy of content maintained by a WebApp Relationships—entity-relationship diagram or UML Hierarchy—data tree or UML These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 32 Data Tree Market ingDescript ion Phot ograph part Number TechDescript ion part Name component Schemat ic part Type Video descript ion price WholesalePrice Ret ailPrice Figure 1 8.3 Dat a t ree for aSafeHome component These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 33 The Interaction Model Composed of four elements: use-cases sequence diagrams state diagrams a user interface prototype Each of these is an important UML notation and is described in Appendix I These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 34 Sequence Diagram :Product :Billof FloorPlan BoM :Room :FloorPlan Component Mat erials Reposit ory Reposit ory new cust omer describes room* places room in f loor plan save f loor plan conf igurat ion select s product component * add t o BoM save bill of mat erials Figure 18.5 Sequence diagram for use-case:select SafeHome components These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 35 State Diagram Validating user Selecting user action userid select other functions system status=“input ready” validated system status=“link ready” select “log-in” display msg = “enteruserid” display: navigation choices” display msg =“enterpswd” password validated entry/ validated user entry/ log-in requested n e w cu st o me r do: link as required do: run user validation exit/user action selected exit/set user access switch customization complete select e-commerce (purchase) functionality select customization functionality next selection Saving floor plan Customizing select descriptive content system status=“input ready” system status=“input ready” Defining room select descriptive display: storage indicator display: basic instructions content room being defined system status=“input ready” entry/ floor plan save selected display: roomdef. window do: store floor plan entry/validated user exit/save completed do: process user selection entry/ roomdef. selected exit/ customization terminated all rooms do: run room queries defined do: store room variables exit/room completed Building floor plan select descriptive select save floor plan content system status=“input ready” select enter room in floor plan display: floor plan window entry/ floor plan selected do: insert room in place do: store floor plan variables exit/room insertion completed room insertion completed Figure 18.6 Part ial st at e diagram f or new cust omer int eract ion These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 36 The Functional Model The functional model addresses two processing elements of the WebApp user observable functionality that is delivered by the WebApp to end-users the operations contained within analysis classes that implement behaviors associated with the class. An activity diagram can be used to represent processing flow These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 8/e (McGraw-Hill 2014). Slides copyright 2014 by Roger Pressman. 37 Activity Diagram init ialize t ot alCost no components remain onBoMList components remain onBoMList invoke get price and calcShippingCost quant it y ret urns: shippingCost lineCost = price x quant it y invoke det ermineDiscount ret urns: discount add lineCost t o t ot alCost discount>0 t ot alCost= t ot alCost - discount discount