Structuring System Process Requirements

Structuring System Process Requirements
Chapter 7 Structuring System Process Requirements System modeling

Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall
Process Modeling FIGURE 7-1 Systems development life cycle with the analysis phase highlighted Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Process Modeling (Cont.)
Graphically represent the processes that capture, manipulate, store, and distribute data between a system and its environment and among system components. Utilize information gathered during requirements determination. Model processes and data structures. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

System modeling System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). 30/10/2014 Chapter 7 System Modeling

System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Existing and planned system models
Models of the existing system are used during requirements engineering to: -help clarify what the existing system does -used as a basis for discussing its strengths and weaknesses. -help explain the proposed requirements to other system stakeholders. -Used by SW Engineers(system analysts) to discuss design proposals and to document the system for implementation. 30/10/2014 Chapter 7 System Modeling

Modeling methods used in this course are:
Context diagram DFD : Data Flow Diagram(level 0 and 1) UML ( use case, class diagrams) EERD : Extended Entity Relationship Diagram (explained in database course) 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

1-Context diagram(models)
It is an overview of an organizational system that shows: the system boundaries. external entities that interact with the system. major information flows between the entities and the system. Note: only one process symbol, and no data stores shown in the context diagram. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Context models(cont) Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. They simply show the other systems in the environment, not how the system being developed is used in that environment. 30/10/2014 Chapter 7 System Modeling

System boundaries System boundaries are established to define what is inside and what is outside the system. They show other systems that are used or depend on the system being developed. The position of the system boundary has a profound (عميق)effect on the system requirements. 30/10/2014 Chapter 7 System Modeling

The figure below shows a context Data Flow Diagram that is drawn for a Food Ordering System. It contains a process (shape) that represents the system to model, in this case, the "Food Ordering System". It also shows the participants who will interact with the system, called the external entities. In this example, Supplier, Kitchen, Manager and Customer are the entities who will interact with the system. In between the process and the external entities, there are data flow (connectors) that indicate the existence of information exchange between the entities and the system. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

food ordering system context diagram
Context DFD is the entrance of a data flow model. It contains one and only one process and does not show any data store.

The context of the Mentcare system
30/10/2014 Chapter 7 System Modeling

2-Data Flow Diagramming
A data flow diagram (DFD) is a graphical representation of the "flow“ of data through an information system, modelling its process aspects. A DFD is often used as a preliminary step to create an overview of the system, which can later be elaborated. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Definitions and Symbols
FIGURE 7-2 Comparison of DeMarco and Yourdon and Gane and Sarson DFD symbol sets Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Definitions and Symbols (Cont.)
Process: work or actions performed on data (inside the system) Data store: data at rest (inside the system) Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Definitions and Symbols (Cont.)
Source/sink: external entity that is the origin or destination of data (outside the system) Data flow: arrows depicting movement of data Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Developing DFDs (Cont.)
Level 1 DFD: is the decomposition (i.e. break down) of the Food Ordering System process shown in the context DFD. Level-1 diagram is a data flow diagram that represents a system’s major processes, data flows, and data stores at a high level of detail. Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive (lower-level) DFDs. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

The Food Order System Data Flow Diagram example contains three processes, four external entities and two data stores. Based on the diagram, we know that a Customer can place an Order. The Order Food process receives the Order, forwards it to the Kitchen, store it in the Order data store, and store the updated Inventory details in the Inventory data store. The process also deliver a Bill to the Customer. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Manager can receive Reports through the Generate Reports process, which takes Inventory details and Orders as input from the Inventory and Order data store respectively. Manager can also initiate the Order Inventory process by providing Inventory order. The process forwards the Inventory order to the Supplier and stores the updated Inventory details in the Inventory data store. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Data Flow Diagramming Rules
There are two DFD guidelines that apply: The inputs to a process are different from the outputs of that process. Processes purpose is to transform inputs into outputs. Objects on a DFD have unique names. Every process has a unique name. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Data Flow Diagramming Rules (Cont.)
TABLE 7-2 Rules Governing Data Flow Diagramming Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Data Flow Diagramming Rules (Cont.)
TABLE 7-2 Rules Governing Data Flow Diagramming (cont.) Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

DFD Diagramming Rules Process
No process can have only outputs or only inputs…processes must have both outputs and inputs. Process labels should be verb phrases.

DFD Diagramming Rules Data Store
All flows to or from a data store must move through a process. Data store labels should be noun phrases.

DFD Diagramming Rules Source/Sink
No data moves directly between external entities without going through a process. Interactions between external entities without intervening processes are outside the system and therefore not represented in the DFD. Source and sink labels should be noun phrases.

DFD Diagramming Rules Data Flow (cont.)
Joined data flow must refer to exact same data item (not different data items) from multiple sources to a common location. Data flow cannot go directly from a process to itself, must go through intervening processes.

DFD Diagramming Rules Data Flow
Bidirectional flow between process and data store is represented by two separate arrows. Forked data flow must refer to exact same data item (not different data items) from a common location to multiple destinations.

Decomposition of DFDs Functional decomposition is an iterative process of breaking a system description down into finer and finer detail. Creates a set of charts in which one process on a given chart is explained in greater detail on another chart. Continues until no subprocess can logically be broken down any further. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Decomposition of DFDs (Cont.)
Primitive DFD is the lowest level of a DFD. Level-1 diagram results from decomposition of Level-0 diagram. Level-n diagram is a DFD diagram that is the result of n nested decompositions from a process on a level-0 diagram. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Guidelines for Drawing DFDs
Completeness DFD must include all components necessary for system. Each component must be fully described in the project dictionary. Consistency The extent to which information contained on one level of a set of nested DFDs is also included on other levels Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Guidelines for Drawing DFDs (Cont.)
Timing Time is not represented well on DFDs. Best to draw DFDs as if the system has never started and will never stop. Iterative Development Analyst should expect to redraw diagram several times before reaching the closest approximation to the system being modeled. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Rules for stopping decomposition
When each process has been reduced to a single decision, calculation or database operation When each data store represents data about a single entity When the system user does not care to see any more detail When every data flow does not need to be split further to show that data are handled in various ways Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Level-2 DFD FIGURE 7-8 Level-2diagram showing the decomposition of Process 4.0 from the level-1 diagram for Hoosier Burger’s food-ordering system Level-2 DFD shows the sub-processes of one of the processes in the Level-1 DFD. This is a Level-2 DFD for Process 4.0. Processes are labeled 4.1, 4.2, etc. These can be further decomposed in more primitive (lower-level) DFDs if necessary. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Level-n DFD FIGURE 7-9 Level-2 diagram showing the decomposition of Process 4.3 from the level-1 diagram for Process 4.0 for Hoosier Burger’s food-ordering system Level-n DFD shows the sub-processes of one of the processes in the Level n-1 DFD. This is a Level-2 DFD for Process 4.3. Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest level of the hierarchy, it is called a primitive DFD. Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Balancing DFDs Balancing: conservation of inputs and outputs to a data flow diagram process when that process is decomposed to a lower level. Balanced means: Number of inputs to lower level DFD equals number of inputs to associated process of higher-level DFD Number of outputs to lower level DFD equals number of outputs to associated process of higher-level DFD Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Balancing DFDs (Cont.) FIGURE An unbalanced set of data flow diagrams (a) Context diagram 1 input 1 output This is unbalanced because the process of the context diagram has only one input but the Level-0 diagram has two inputs. (b) Level-0 diagram 2 inputs 1 output Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Example 2 – context diagram

next step - the Next Level(s) Each Process box in the Top Level diagram will itself be made up of a number of processes, and will need to be decomposed as a second level diagram. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Each box in a diagram has an identification number derived from the parent - in the top left corner. (The Context level is seen as box 0) Any box in the second level decomposition may be decomposed to a third and then a fourth level. Very complex systems may possibly require decomposition of some boxes to further levels. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Decomposition stops when a process box can be described with an Elementary Process Description using ordinary English, later on the process will be described more formally as a Function Description using, for example, pseudocode. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

The next step - the Next Level(s) Each Process box in the Top Level diagram will itself be made up of a number of processes, and will need to be decomposed as a second level diagram. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Redrawing the diagram makes it clear that Process 3, 'Maintain Credit Rating' requires some input - if it is to produce output. Note that 'Goods', while it is in reality a physical thing, is seen here as data. This is because this is a model. We will represent 'Goods' in our model by some description. In the model, 'Goods' becomes a set of data items. In the real-world, there will be some physical objects, but in our model we only have an astract description. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

UML diagram types The Unified Modeling Language (UML) is a general-purpose, developmental, modeling language in the field of software engineering, that is intended to provide a standard way to visualize the design of a system. UML has 14 different graph models. We are going to study and use two of them: A- Use case diagrams, which show the interactions between a system and its environment. B-Class diagrams, which show the object classes in the system and the associations between these classes. 30/10/2014 Chapter 7 System Modeling

Use case A use case diagram captures the business processes carried out in the system. Use case classes are used to model and represent units of functionality or services provided by a system (or parts of a system: subsystems ) to users. A use case diagram is quite simple in nature and depicts two types of elements: A- one representing the business roles B- one representing the business processes. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Use-case diagram components:
1- Actors: An actor represent any entity (or entities) that perform certain roles in a given system. The different roles the actor represents are the actual business roles of users in a given system. An actor in a use case diagram interacts with a use case. For example, for modelling a banking application, a customer entity represents an actor in the application. Similarly, the person who provides service at the counter is also an actor. An actor is shown as a stick figure in a use case diagram depicted "outside" the system boundary. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Types of actors: Actors can be primary or secondary actors. Primary actors initiate a use case, triggers the use case. Supporting or secondary actors support a use case or receive something of value from the use case. Actors can be:Human, Systems/Software, Hardware, Timer/Clock 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Actors Actors have the following characteristics: 1- Actors are external to a system. 2- Actors interact with the system. Actors may use the functionality provide by the system, including application functionality and maintenance functionality. 3- Actors may provide functionality to the system. Actors may receive information provided by the system. Actors may provide information to the system. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Actors example Figure 1 shows a project management system with a project manager actor and a project database actor. The project manager is a user who is responsible for ensuring the success of project and uses the system to manage projects. The project database is a system that is responsible for housing project management data. Figure 1 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Examples A bank loan officer wants to review a loan application from a customer, and part of the process involves a real-time credit rating check. Use Case Name: Review Loan Application Primary Actor: Loan Officer Secondary Actors: Credit Rating System A Human Resources manager wants to change the job code of an employee, and as part of the process, automatically notify several other departments within the company of the change. Use Case Name: Maintain Job Code Primary Actor: Human Resources Manager Secondary Actors: None 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

UML Use Case Diagram Symbols
Actor Boundary Connection Include relationship Extend relationship <<include>> <<extend>>

Transfer-data use case
A use case in the Mentcare system 30/10/2014 Chapter 7 System Modeling

To identify an actor, search in the problem statement for business terms that represent roles in the system. For example, in the statement "patients visit the doctor in the clinic for medical tests," "doctor" and "patients" are the business roles and can be easily identified as actors in the system. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Use cases in a use case diagram

identifying use cases Use case: As the first step in identifying use cases, you should list business functions in your problem statement. Each of these business functions can be classified as a potential use case. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

System boundary: A system boundary defines the scope of what a system will be. A system cannot have infinite functionality. So, it follows that use cases also need to have definitive limits defined. A system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a rectangle spanning all the use cases in the system. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

A use case diagram depicting the system boundary of a clinic application Note that the actors in the system are outside the system boundary. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Relationships in Use Cases
Use cases share different kinds of relationships. A relationship between two use cases is basically a dependency between the two use cases. This reuse of an existing use case using different types of relationships reduces the overall effort required in defining use cases in a system. A similar reuse established using relationships, will be apparent in the other UML diagrams as well. Use case relationships can be one of the following: 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

1- Include: When a use case is depicted as using the functionality of another use case in a diagram, this relationship between the use cases is named as an include relationship. in an include relationship, a use case includes the functionality described in another use case as a part of its business process flow. A key here is that the included use case cannot stand alone, i.e., one would not validate the patient record without making an appointment. The stereotype "<<include>>" identifies the relationship as an include relationship. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

An example of an include relationship
For example, you can see that the functionality defined by the "Validate patient records" use case is contained within the "Make appointment" use case. Hence, whenever the "Make appointment" use case executes, the business steps defined in the "Validate patient records" use case are also executed. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

2- Extend: In an extend relationship between two use cases, the child use case adds to the existing functionality and characteristics of the parent use case. An extend relationship is depicted with a directed arrow having a dotted shaft, similar to the include relationship. The tip of the arrowhead points to the parent use case and the child use case is connected at the base of the arrow. The stereotype "<<extend>>" identifies the relationship as an extend relationship, as shown: 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

An example of an extend relationship

The figure shows an example of an extend relationship between the "Perform medical tests" (parent) and "Perform Pathological Tests" (child) use cases. The "Perform Pathological Tests" use case enhances the functionality of the "Perform medical tests" use case. Essentially, the "Perform Pathological Tests" use case is a specialized version of the generic "Perform medical tests" use case. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Use cases in the Mentcare system involving the role ‘Medical Receptionist’

Time is an external effect outside of the control of the system. When a certain time is reached that event is detected by the real-time clock that is inside the system and the use case is started 'automatically'. It would usually be too inflexible to hardcode the system always to start at a particular time, so normally an actor, through another use case or through the same use case, would be able to turn the automation on and off and set the time. 5/14/2018Chapter 7 Copyright © 2014 Pearson Education, Inc. Publishing as Prentice Hall

Class diagrams Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. An object class can be thought of as a general definition of one kind of system object. An association is a link between classes that indicates that there is some relationship between these classes. When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc. 30/10/2014 Chapter 7 System Modeling

UML classes and association

Classes and associations in the MHC-PMS

The Consultation class
30/10/2014 Chapter7 System Modeling

Structuring System Process Requirements

Similar presentations

Presentation on theme: "Structuring System Process Requirements"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Structuring System Process Requirements

Similar presentations

Presentation on theme: "Structuring System Process Requirements"— Presentation transcript:

Similar presentations

About project

Feedback