Unit 3 - From domain modelling to requirements

Question 1

What is a business rule?

Answer 1

Business rules constrain how a business is run. They are not specific to any project but they influence each project’s development – they typically include policies, physical laws, government laws, etc. Business rules reflect the way the business works, independently of any new system being introduced in that business domain

Question 2

What are the important properties that a representation of business rules should have?

Answer 2

• Business rules that apply to the whole business should be represented separately from project specific models.
• They should be easy to verify (possibly automatically) and validate.
• They should be represented in a readable language that is easy to verify.

SAQ 1

Question 3

Name two aspects of software development where use case modelling can help.

Answer 3

So far we have encountered these two: eliciting requirements; representing requirements. Later in the module we will also discuss planning iterations of development and validating software systems.

SAQ 4

Question 4

Consider whether business rules can be modelled in UML. What are the consequences ?

Answer 4

UML can support the specification of business rules either as annotations to the models or in a more formal way through OCL. However UML and OCL do not provide a separate explicit notation for business rules.

As a consequence, it does not:

• facilitate documentation of the rules independently of other models;
• facilitate their analysis, validation and change;
• facilitate their traceability from the business needs to the software solution.

SAQ 1

Question 5

What causes a transition in an activity diagram?

Answer 5

A transition in an activity diagram is caused by the completion of an activity.

SAQ 2

Question 6

What is a synchronisation bar, and when is one used in an activity diagram?

Answer 6

A synchronisation bar is used to mark the point when two or more activities can take place concurrently (a fork) or when a number of concurrent tasks must finish before continuing to the next activity (a join).

SAQ 2

Question 7

How does the partitioning of activities into swimlanes help us understand a set of activities?

Answer 7

Swimlanes group activities associated with different roles. The swimlanes show the role that is responsible for each activity.

SAQ 3

Question 8

Give one reason for modelling a workflow in an activity diagram.

Answer 8

Activity diagrams represent the sequence of activities. When you are modelling a workflow that involves more than one role, it is possible to identify which role is responsible for a particular activity. An activity diagram can help identify the stages at which each role requires some interaction with the process.

SAQ 3

Question 8

What are the elements in a use case diagram?

Answer 8

• the actors, represented by stick figures
• the use cases, represented by ovals
• the relationships between actors and use cases – their associations – represented by lines.
  p. 146

Question 10

Suggest a reason why use case diagrams are an aid to communication between user and developer.

Answer 10

Use cases offer users an opportunity to understand the system since the use case notation is relatively simple and doesn’t require an understanding of UML. This provides a mechanism that enables developer and client to share a common understanding of the system, as long as the developer provides some text to demonstrate their understanding of the problem.

SAQ 4

Question 11

What is the purpose of a system boundary? Is it always necessary to draw one in a use case diagram?

Answer 11

The purpose of a system boundary is to identify a single system, distinguishing between the internal and external components. Typically, the external components are the actors and the internal components are the use cases. UML says that the system boundary is optional.

SAQ 5

Question 12

Explain why the actors in a use case diagram do not represent actual individuals.

Answer 12

An actor in a use case diagram represents a particular role that an individual might play when interacting with a software system. For example, a receptionist checks guests into and out of a hotel (see Figure 10). But it could be that the person who works as a receptionist at one hotel becomes a guest at another hotel in the chain and hence takes on another role. Actors can also represent other systems, rather than people/roles.

SAQ 6

Question 13

Suggest a guideline that will help you decide whether or not to include an interaction with an external system on your use case diagram.

Answer 13

One possible guideline would be to show interaction with an external system if the use case needs to communicate with the actors that represent the external system.
SAQ 6

Question 13

What are ‘business processes’?

Answer 13

Business processes define what is done in a business, by whom, in what order, needing which resources, and with what consequences.

Question 14

Are roles in business process models the same as actors in use cases?

Answer 14

Roles in business process models may not correspond directly to actors in use cases as although they interact with a business process they may not interact with a proposed system. Some roles may become irrelevant when introducing a new system or may not need to interact with the system.

SAQ 6

Question 15

What should a use case description always consist of?

Answer 15

• a unique identifier for the use case, to allow traceability throughout development
• the name of the actor that initiates the use case
• a short description of the goal of the use case
• a single sequence of steps that describe the main success scenario
• a textual description of the pre- and postconditions.

p. 154

Question 16

What is the relationship between a use case and a scenario? Give examples to illustrate your answer.

Answer 16

For each use case there is a set of possible scenarios. A scenario is an instance of a use case. A scenario describes a sequence of interactions between the system and some actors.

Examples:

1. A member of a lending library wishes to borrow a book, and is allowed to do that as long as they have no outstanding loans.
2. Another member wishes to borrow a book, but has exceeded the quota for the number of books that can be borrowed.

In each scenario the member wishes to borrow a book, but both the circumstances and outcomes of events are different in each instance. So a use case includes a complex set of requirements that the system must meet in order to cope with every eventuality.

SAQ 7

Question 17

What is meant by a main success scenario?

Answer 17

The main success scenario shows the steps normally followed to achieve the stated goal of the use case. But there can be other scenarios for the same use case, each one having different outcomes depending upon circumstances.

SAQ 7

Question 18

How do use cases help with requirements capture?

Answer 18

Use cases help with requirements capture through the identification of actors and tasks in the system. For each actor, the set of use cases establishes what that actor requires from the software system. The association between an actor and a use case is about communication.

SAQ 8

Question 19

How do use cases help with the elicitation of detailed software requirements?

Answer 19

Detailed software requirements can be associated with each step in a use case scenario. There may be more than one requirement for each step.

SAQ 8

Question 20

How do use cases help with development?

Answer 20

The use case descriptions help the developer to:

• understand the complexity of each use case
• determine which actors interact with each use case and to what extent
• establish which use cases carry the most risk
• estimate how long each use case is likely to take to implement.
  SAQ 8

Question 21

How do use cases help with the system’s architecture?

Answer 21

Use cases, as standalone chunks of system specification, dictate the sorts of functionality that need to be provided by the system and constitute an aid for identifying interfaces in an architecture. Use cases can also be grouped in terms of similar functionality, therefore influencing the architecture of the system. Scenarios can be used to check how an architecture meets non-functional requirements, in particular those that can be affected by the architecture, such as security and safety requirements.

SAQ 8

Question 22

How do use cases help with requirements system validation?

Answer 22

One way to validate a system is to use the walk-through technique, checking the functionality related to each use case in turn. The walk- through technique can also be used to elicit system tests where each use case is required to deal with a number of scenarios – a process known as verification. For each software requirement generated from a step of a scenario, the fit criterion helps to devise the test.

SAQ 8

Question 23

What is the purpose of identifying relationships between actors?

Answer 23

The purpose of identifying relationships between actors is to indicate generalisations and establish which use cases can be performed by which actors.

SAQ 9

Question 24

What is a stereotype in UML?

Answer 24

A stereotype is a way of attaching extra classifications to a model adding to its basic language. Stereotypes can be user defined – this is a way of extending UML.

SAQ 10

Question 25

What is the meaning of the «include» stereotype?

Answer 25

The «include» stereotype indicates a situation where a use case is reused.

SAQ 10

Question 26

What is the meaning of the «extend» stereotype?

Answer 26

The «extend» stereotype indicates a conditional extension to the original use case, known as alternative behaviour. This is used to illustrate a case where there are two or more significantly different scenarios, so that the main case and the additional subsidiary cases are clearly differentiated. The main purpose of this classification is to separate out a special case. You should add a condition to each extension – with either a note or an extension point – to specify when the variant behaviour will be included.

SAQ 10

Question 27

Is it necessary to place the «include» and «extend» stereotypes on all
diagrams?

Answer 27

No, it is not necessary to place the «include» stereotype and the «extend» stereotype on all diagrams. In fact, in some situations they can cause confusion since they will not be understood by everyone.

SAQ 10

Question 28

How would you modify a use case model to show that you intend to employ a component that already exists?

Answer 28

Each use case that benefits from the component must have a relationship to that component shown on the diagram. This relationship should have the «include» stereotype attached to it.

SAQ 10

Question 29

What problems may arise when developing a software system from a set of use cases?

Answer 29

One problem is that the focus may end up being top-down and function- oriented, resulting in an inflexible and difficult-to-maintain system. Focusing on use cases may cause the developer to sacrifice the object- oriented nature of the system, thus losing any advantage that UML offers.
Another danger lies in mistaking design for requirements, where a design decision is mistaken for a constraint. Focusing on the requirements in a use case may cause the developer to view the system too operationally, where a sequence of events is assumed to be the only answer. Developers need to distinguish between requirements and preferred designs.
Use cases need to be used in a way that is understandable to the customer but also useful to the developer.

SAQ 11

Question 30

What are the tasks involved in preparing a use case model (for a moderately large system) intended for the development team?

Answer 30

. defining the context for the model by identifying the actors involved in the aspect of the system in question
. analysing the behaviour that each actor expects from the proposed system, and identifying the use cases (as units of functionality within the overall requirements)
. identifying the common behaviour that may be reused by other actors, and the variations on common behaviour (the stereotypes «include» and «extend»)
. drawing a model that shows the use cases, the actors and the relationships between them
. annotating the use cases as you learn more about the requirements.

p. 177

Question 31

Who initiates the prototyping process?

Answer 31

The developers would normally start the prototyping process because they have detected or identified a particular problem in their requirements analysis. (But note that the project manager would need to get approval from the customer for the additional effort.)

SAQ 12

Question 32

Who should test a prototype?

Answer 32

The intended users should test it. For example, if you developed a series of interfaces as part of a prototype for the borrowing and returning of books, the library members would be the testers.

SAQ 12

Question 33

What is the main benefit of identifying user interfaces in your activity diagrams?

Answer 33

The main benefit of recording user (or any other) interfaces in an activity diagram is traceability. To the users, the interface is the software system: an unacceptable interface can lead to failure. The user interface is the link between what the users want and what the developer produces in response.
Also, the developer can identify the relative importance of each user interface for the project plan, particularly when resources are needed for a prototype.

SAQ 13

Question 34

Suppose the developer built a prototype interface that could deal with all identified use cases in the first iteration of the library system. Suggest a criterion that a librarian might use when evaluating the prototype, which goes beyond the completion of the underlying tasks within each use case.

Answer 34

This was the example we thought of, but you may have thought of others. Librarians may find it essential that the system makes it very easy to switch between different tasks. They will expect the prototype to provide evidence that the eventual system will meet this criterion.

SAQ 13

Question 35

What are the main differences between a use case and a user story?

Answer 35

A use case describes a business process or a self-contained task within a process. It is as complete as possible, lasts as a document, is agreed (by customers and developers) and is used to generate requirements.

A user story is small enough to be implemented in a single iteration, represents an instance from a user perspective, is not complete, does not last and instead is used as a reminder for a conversation.

Unit 4, SAQ 2