Topic # 03. Requirements to Software System: An Overview (Ch. 5 and partially Ch. 6)

Transcription

1 Topic # 03 Requirements to Software System: An Overview (Ch. 5 and partially Ch. 6) 1 Understanding Requirements: An Overview This topic is an overview of Requirements Engineering (RE), and RE is the initial part of huge area in SE Analysis, Design & Modeling/Testing/Prototyping/Simulation. CS 592 is Requirements Engineering class (with a lot of details on RE including partially UML language) for both undergrad and graduate students is available at the Computer Science curriculum. RE helps software engineers better UNDERSTAND customer needs, desires, requirements and the problems they are trying to solve. *) Building an elegant computer solution that ignores the customer s needs helps no one. It is very important to understand the customer s wants and needs before you begin designing or building a computer-based software solution. *) Example: in Best Buy The intent of RE is to produce a written formal understanding of the customer s problem using prof. language of diagrams (not just in plain text form). Several work outcomes might be used to communicate this understanding, including: - list of main users/actors, - list of main functions and features, - Use-Case scenarios (SwimLane Diagrams, Activity Diagrams, etc.), - Data Objects (DOs) diagrams and Class Objects (COs) Diagrams, - Data Flow Diagrams (DFDs), - Entity-Relationships Diagrams (ERDs), - State Transition Diagrams (STDs), and many other possible analysis models). 2

2 SE Requirements: Analysis Model as a Bridge System Description (by a customer) system description List of SW System Specifications (diagrams that SW engineers and SW developers understand) analysis model design model Lists of SW system Requirements (that customer still understands) System Development by SW technologists and technicians 3 Requirements Engineering: 6 Majors Steps The software requirements engineering process has 6 distinctive steps: 1) inception (initiation, i.e. basic understanding of a problem, people who want a solution; nature of desired solution, user environment, etc. ), 2) elicitation (drafting of requirements, possible approaches to solve problem, technology, manpower, etc.), 3) elaboration (building an analysis model, i.e. the way SE understood what customer wants but using a professional language of diagrams), 4) negotiation (discussions with a customer), 5) problem specification (written documents/statements/diagrams/prototypes/ proposed specs, i.e. customer requirements using professional language), and 6) validation (review) of the proposed specifications (specs) with a customer and professionals (i.e. coverage of essential features; clarity of requirements and their details; sources for each requirement; potential conflicts, etc.) RE must be adapted to the needs/specifics of a particular project, process, product, or people doing the work. In some cases RE may be abbreviated (shortened), but it is never abandoned. 4

3 Software Requirements Engineering Strategies 1) OLD STYLE: a written document with detailed identifies technical specifications, 2) MODERN (VERY PROFESSIONAL) STYLE: a set of graphical models diagrams, 3) (AGILE STYLE): a working prototype (probably with very limited 5-10% - number of all required/requested functions) 5 Main Components of the SW Analysis Model Analysis Model 1. Scenario-based models: - use-cases textual; - use-cases diagrams; - activity diagrams; - swim lane diagrams; 2. Class models: - class diagrams; - analysis packages; - collaboration diagrams. 3. Behavioral models: - state transition diagrams; - sequence diagrams. 4. Data-flow models: - data-flow diagrams; - ERD diagrams; - control-flow diagrams; - processing narratives; 6

4 Data Objects 7 What is a Data Object? Data Object - something that is described by a name and a set of attributes (data items) and that will be manipulated within the software (system) each instance of an object (e.g., a book) can be identified uniquely (e.g., ISBN #) each plays a necessary role in the system i.e., the system could not function without access to instances of the object each is described by attributes that are themselves data items Data Object Name: Student Data Object Attributes: firsrt_name last_name year_of_admission major courses_taken credits_obtained home_address phone_number address etc. 8

5 What is a Data Object? (cont.): attributes + data type + length Data Object Name: Student Data Object Attributes: firsrt_name last_name year_of_admission major courses_taken credits_obtained home_address phone_number address etc. Examples: String FirstName [???] String LastName [???] String SSN [11] Char SSN [11] Integer BradleyID [6] 9 Typical Data Objects external entities things occurrences or events roles organizational units places data structures (printer, user, sensor) (e.g, reports, displays, signals) (e.g., interrupt, alarm) (e.g., manager, engineer, salesperson) (e.g., division, team) (e.g., manufacturing floor) (e.g., employee record, file, etc.) 10

6 Modern CASE Systems (diagramming tools) 11 Class Objects 12

7 Class Diagrams Class Diagrams are actively used on Class-based Modeling Represents: 1) objects system manipulates 2) operations applied to objects, and 3) collaborations occurring between classes Elements of class model include: 1) data objects 2) attributes 3) operations Examine the problem statement and try to find nouns that fit the following categories and produce or consume information (i.e. grammatical parse) External entities (systems, devices, people) Things (e.g. reports, displays, letters, signals) Events occurring during system operation Roles (e.g. manager, engineer, salesperson) Organizational units (e.g. division, group, team) Places 13 Structures (e.g. sensors, vehicles, computers) FROM data Objects TO Class Objects What are 4 main concepts of class-oriented or objectoriented approach? Abs Enc. Enh.. Pol 14

8 Class-Based Modeling: Data Objects with Attributes and Functions/Methods/Operations A data object contains a set of attributes that act as an aspect, quality, characteristic, or descriptor of the object Class Object Name: Student Class Object Attributes: firsrt_name last_name year_of_admission major courses_taken credits_obtained home_address phone_number address etc. Class Object Functions/Methods: register for a course pay for a course get individual course schedule etc. 15 Class Diagram -- Student Class (1/2): Example of a Conceptual Sketch Source: 16

9 Class Diagram Student Class (2/2): An example of the initial conceptual class diagram Classes (data objects, Ch.6) Attributes Operations Associations: enrolled, on waiting list, etc. Source: 17 Software Engineering course: Domain for most of homework assignments Webster current Bradley Online Course Registration System Webster++ new system that contains proposed-by-you modifications/improvements to be 18

10 Current Webster System: Possible Class Objects 19 Use-Case Scenarios 20

11 Use-Cases and Use-Case Scenarios USE CASE is a collection of user scenarios that describe the thread of usage of a system how different users use an old software system or how they will would like to use a new one. Each SINGLE USECASE SCENARIO is described from the point-of-view of an actor a person or device that interacts with the software in some way Each SINGLE scenario answers the following questions: Who is the primary actor (user), the secondary actor (s)? What are the actor s goals? What preconditions should exist before the story begins? What main tasks or functions are performed by the actor? What extensions might be considered as the story is described? What variations in the actor s interaction are possible? What system information will the actor acquire, produce, or change? Will the actor have to inform the system about changes in the external environment? What information does the actor desire from the system? Does the actor wish to be informed about unexpected changes? 21 Use Case Diagram in UML Diagram format It is easy to mix up the definitions of use case and use case scenario. A use case (as a class) represents ALL actions that are required to enable or abandon a goal. A use case has multiple paths that can be taken by any user at any one time. A use case scenario is a single path through the use case. How to create Use-Cases (an algorithm): 1) Identify all USERS of a new system (human beings, non-human beings, other SW applications, online databases, etc.) 2) Identify all FUNCTIONES (FEATURES) of a new system 3) Identify RELATIONS between USERS and FUNCTIONS. Source: 22

12 A Possible Use Case Diagram for current Webster System 23 A Possible Use Case Diagram in for new Webster System How to create Use-Case (an algorithm): 1) Identify all USERS of a new system (human beings, non-human beings, other SW applications, online databases, etc.) 2) Identify all FUNCTIONES (FEATURES) of a new system 3) Identify RELATIONS between USERS and FUNCTIONS. 24

13 Activity Diagram 25 Activity Diagram (for one type of users) enter password and user ID valid passwor ds/ ID invalid passwor ds/ ID Supplements the use case by providing a graphical representation of DETAILED ALGORITHM of data flow (step-by-step) of interaction within a specific scenario select major function prompt for reentry ot her f unct ions m ay also be select ed input t r ies r em ain select surveillance no input t r ies r em ain t hum bnail views select a specif ic cam er a For example: TO ADD COURSE function: select specific camera - thumbnails select camera icon Step 1: Step 2:.. Step N: view camera out put in labelled window prompt for another view exit t his f unct ion see anot her camera 26

14 Sequence Diagram 27 Sequence Diagram (examples) Source: 28

15 Source: 29 SwimLane Diagrams 30

16 h o m e o w n e r c a m e ra i n t e rf a c e Swimlane Diagrams enter password and user ID Allows the modeler to represent the flow of activities described by the use-case and at the same time indicate which actor (if there are multiple actors involved in a specific use-case) or analysis class has responsibility for the action described by an activity rectangle select major function o t h er f u n ct io n s m ay also b e select ed selec t surv eillance t h u m b n ail views select a sp ecif ic cam er a valid p asswo rds/ ID in valid p asswo r d s/ ID prompt for reentry input tries r em ain n o inpu t t r ies r em ain select specif ic camera - thumbnails select camera icon generate video output v iew cam era out put in labelled window prom pt for another view exit this f u n ct io n see an o t h er cam er a 31 Use-Case (a collection of possible cases = paths) and Use-Case Scenario (a single path given in yellow color) on a SwimLane Diagram *) Example: SwimLane diagram of Webster by CS390 student (in 2015) Source: 32

17 Topic # 03 Requirements to Software System: An overview Homework Assignment 33 Topic # 03 SW Requirements Engineering: Additional Information 34

18 Step 1: Inception (initiating RE process) Inception ask a set of questions that establish basic understanding of the problem the people who want a solution the nature of the solution that is desired, and the effectiveness of preliminary communication and collaboration between the customer and the developer Main activities on this step (ask millions of good professional questions) : Identify stakeholders (who are interested in such an application) and their viewpoints Questions of type A: Focus on customer, stakeholders, overall goals, and benefits of the system Who is behind the request for work? Who will use the solution? What will be the economic benefit of a successful solution? Is there another source for the solution needed? Questions of type B: Understand the problem and the customer s perceptions of the solution How would you characterize good output form a successful solution? What problem(s) will this solution address? Can you describe the business environment in which the solution will be used? Will special performance constraints affect the way the solution os approached? Questions of type C: Focus on communication effectiveness Are you the best person to give official answers to these questions? Are my questions relevant to your problem? Am I asking too many questions? Can anyone else provide additional information? Should I be asking you anything else? 35 Step 2: Eliciting (Drafting of) Requirements The goal is to identify the problem (if possible) to suggest quickly elements of the solution to negotiate different approaches, and to specify a preliminary set of solution requirements Collaborative requirements gathering guidelines Meetings attended by both developers and customers Rules for preparation and participation are established Flexible agenda is used Facilitator controls the meeting Definition mechanism (e.g. work sheets, stickers, flip sheets, electronic bulletin board) used to determine (estimate) group consensus 36

19 Step 2: Elicitation of Requirements: An Algorithm (Sequence of Actions) using Activity Diagram in UML Conduct FAST m eetings Make lists of functions, classes Make lists of constraints, etc. Elic it requi rem ent s yes form al prioritization? no Use QFD t o prioritize requirem ents inform ally prioritize requirem ents define actors draw use-case diagram write scenario Create Use-cases complete template 37 Step 2: Elicitation Work Products -- The Outcomes Needs: Statement of need and feasibility Scope: Bounded statement of scope for system or product Stakeholders : List of stakeholders involved in requirements elicitation Environment: Description of system s technical environment Users: List of users (or, list of data objects) of deployed system Requirements: List of requirements organized by function and applicable domain constraints Use-Cases: Set of usage scenarios (use-cases) that provide use insight into operation of deployed system Prototypes: Initial prototypes (sketches) developed to better understand requirements 38

20 Step 3: Elaboration (building an analysis model) Analysis Modeling uses a combination of text and diagrammic forms to depict requirements for 1) data, 2) functions, and 3) behavior in a way that is relatively easy to understand, and, moreover, straightforward to review for correctness, completeness, and consistency. As a result, elements of the Requirements or Analysis Model Scenario-based elements o Use-case - descriptions of the interaction between an actor and the system o Functional - processing narratives for software functions Flow-oriented elements o Data flow diagram (DFDs) Class-based elements o Implied by scenarios (class elements, for example: Data Objects) Behavioral elements o State transition diagrams (STDs) 39 Step 3: Main Components of the SW Analysis Model Analysis Model 1. Scenario-based models: - use-cases textual; - use-cases diagrams; - activity diagrams; - swim lane diagrams; 2. Class models: - class diagrams; - analysis packages; - collaboration diagrams. 3. Behavioral models: - state transition diagrams; - sequence diagrams. 4. Data-flow models: - data-flow diagrams; - ERD diagrams; - control-flow diagrams; - processing narratives; 40

21 Step 4: Negotiation with the Customer (inform about your current understanding of a problem and ask additional questions if needed) Goal is to produce a win-win result before proceeding to subsequent software engineering activities Intent is to develop a project plan that meets stakeholder needs and real-world constraints (time, budget, people) placed on the software team Negotiation activities Identification of system key stakeholders Determination of stakeholders win conditions Negotiate to reconcile stakeholders win conditions into win-win result for all stakeholders (including developers) 41 Step 5: Problem Specification It has several meanings in Software Engineering due to type, nature and size of SW project, for example: 1) OLD STYLE: a written document with detailed identifies technical specifications, 2) MODERN (VERY PROFESSIONAL) STYLE: a set of graphical models diagrams, 3) (INTRO STYLE) a collection of usage scenarios (use cases), 4) (AGILE STYLE) a prototype, etc. 42

22 Step 6: Validating Requirements (1/2) SE must be sure that engineered (designed and developed) requirements will provide QUALITY i.e. they will provide clear, precise and concise information/data for the Software Development team, including the following: GOAL. Is each requirement consistent with the overall objective for the system/product? LEVEL OF DETAILS. Have all requirements been specified at the proper level of abstraction? That is, do some requirements provide a level of technical detail that is inappropriate at this stage? COVERAGE OF ESSENTIAL FEATURES. Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective of the system? CLARITY OF REQ. Is each requirement bounded and unambiguous? SOURCES FOR EACH REQ. Does each requirement have attribution? That is, is a source (generally, a specific individual) noted for each requirement? POTENTIAL CONFLICTS. Do any requirements conflict with other requirements? 43 Step 6: Validating Requirements (2/2) ACHIEVABLE REQ. Is each requirement achievable in the technical environment that will house the system or product? TESTABLE REQ. Is each requirement testable, once implemented? CORRECTNESS OF REQ. Does the requirements model properly reflect the information, function and behavior of the system to be built. PARTITIONING OF REQ. Has the requirements model been partitioned in a way that exposes progressively more detailed information about the system. SIMPLICITY OF REQ. Have requirements patterns been used to simplify the requirements model. Have all patterns been properly validated? Are all patterns consistent with customer requirements? 44

23 Modeling of Relationship Between Data Objects ERD (Entity-Relationship Diagrams) 45 What is a Relationship? Relationship - indicates connectedness ; a "fact" that must be "remembered by the system and cannot or is not computed or derived mechanically 1) several instances of a relationship can exist 2) objects can be related in many different ways 46

24 ERD: Cardinality and Modality Cardinality: represents the number of occurrences of object in a given relationship. 1:1 one-to-one (ex: student Bradley ID number) 1:N one-to-many (ex: course number students) M:N many-to-many (ex: students- classes) Modality: represents a need for relationship between 2 objects: Example: Modality of Student Laptop relationship at Bradley University Modality = 0 when there is NO explicit need for relationship to occur (ex: LAS student may have a laptop or not -- it is optional) Modality =1 when an occurrence of relationship is mandatory (ex: CFA student must have a laptop -- it is required) 47 ERD Mechanics 48

25 Use-Case and Use-Case Scenario in UML s Swimlane format Ch. 6, p. 163 (1/2) It is easy to mix up the definitions of use case and use case scenario. A use case (as a class) represents ALL actions that are required to enable or abandon a goal. A use case has multiple paths that can be taken by any user at any one time. A use case scenario is a single path through the use case. Source: 49