Course: Software Development Methods.

Prof. Luca Dan Serbanati

Assist. Prof. Andrei Vasilateanu

 

 

GUIDELINES FOR LABORATORY AND PROJECT ACTIVITY

 

HW1. Business Analysis and Modelling, and User Requirements Analysis

Deliveries: Business Model and Use Case Model

 

First Macro-Activity: Business System Analysis and Modeling

 

In the following figure the main elements of a business system project development is presented.

 

 

To analyse and model a business system, its main components should be first identified and described:

1.      Business Actors (mainly Customer)

2.      Business Processes[1] (Operations, Activities)

3.      Business Agents

4.      Business Objects

5.      Business Rules  

 

Have in mind the following procedure to be applied:

1.      Define the scope of the business process modeling effort

2.      Define business processes based on agreed to priorities

3.      Explore where software can automate, enable, or enhance business processes and understand at a high level how new systems could relate to existing systems and technical infrastructure

4.      Review and refine resulting business operations design

  1. In order to identify the business system components,  answer to the following questions regarding the business system of the “E-Film Hiring” system:

                                  i.          Which are the business actors that interact with the business system?

                                ii.          What is the value produced by the system? (mainly for its customers)

                              iii.          What business activities (operations) have place in the business system?

                              iv.          Which are the business agents that work in the business system?

                                v.          What resources the agents use when they execute the business activities?

                              vi.          What are the business activities that could be automated by including new hardware and software components?

                            vii.          What are the business objects used by and/or obtained after the execution of software components?

 

2.      Construct the Business Use Case Model of the whole system. The Business Use Case Model is a diagram illustrating the scope of the business being modeled. The diagram contains business actors (roles played by organizations, people, or systems external to the business) and the activities (services or functions) they request from the business.

 

Second Macro-Activity: User Requirements Analysis

First Step: Building Use Case Model

 

The following figure shows the relationships between the stakeholders, the business system, and its internal computer-based systems.


 

 

 

 

 

 

 

 

 

 

 

 

 


1.      Define the computer-based system boundary and construct the context diagram of the computer-based system. In order to do this, follow the next steps:

a.       Write the system description consisting from one or two phrases which provide a general, concise description of the system.

b.      Identify the non-developers stakeholders in the business system who are interested in a computer-based system solution. Most of them become the actors of the computer-based system. Describe their objectives and interests.

c.       Delineate the problem domain and implicitly the boundary of the computer-based system.

d.      Identify the primary actors and the computer-based system events they trigger.

 

2.      During this interaction a primary actor generates events to the system, usually requesting some operation in response. For the purposes of software development, the system boundary is usually chosen to be the software (and possibly hardware) system itself; in this context, a system event is an external event that directly stimulates the software. Document the system events in the System Event List. It may contain three event types: data flow, temporal and control. System events  should be expressed at the level of intent rather than in terms of the physical input medium or interface widget level.

 

3.      Construct the Requirements Document like a Use Case Model[2]. In order to do this, follow the next steps:

 

a.       From the stakeholder objectives identify the use cases the system should implement. These use cases specify the system functions deduced from the stakeholders’ concerns and system events. A function of the system should follow the following pattern:

“The system has to do/execute/produce/provide/memorize/store…”

b.      Describe each use case using the use case template provided at the course.  Warning: include both the main and alternative flows. 

 

c.       Add for each use case description the quality attributes you extract from the stakeholders’ objectives: portability, robustness, usability, performances, software or hardware platform on which the system will have to execute, so on.

 

d.      Draw the use case diagram.



[1] A business process is a collection of related structural activities that produce something of value to the organization, its stakeholders or its customers. It is, for example, the process through which an organization realizes its services to its customers. Each business process has inputs, method (transformation, transaction) and outputs. The inputs are a pre-requisite that must be in place before the method can be put into practice. When the method is applied to the inputs, then certain outputs will be created. A business process can be part of a larger, encompassing process and can include other business processes that have to be included in its method. In that context a business process can be viewed at various levels of granularity. The linkage of business process with value generation leads some practitioners to view business processes as the workflows. This is why the UML activity diagram is a valuable conceptual tool for business process description.

[2] The Use Case Model is composed from a diagram illustrating the scope of the application being built and use case descriptions. The diagram contains actors (roles played by people or systems external to the application being built) and uses cases that is the services or functions the actors request from the application.

Do not confuse Business Use Case Model with the Use Case model! A single Business Use Case Model may have many (system) Use Case Models associated with it, where each Use Case Model represents a single computer-based application.