Presentation is loading. Please wait.

Presentation is loading. Please wait.

Requirements Engineering Tutorial

Similar presentations


Presentation on theme: "Requirements Engineering Tutorial"— Presentation transcript:

1 Requirements Engineering Tutorial
Tutorial outline Requirements engineering Basic concepts Requirements engineering process for ARENA REQuest: Live Demonstration REQuest: Guidelines Summary & next steps Another interesting issue with finding objects is to define which objects are inside the application domain and which ones are outside of it. Sometimes it helps you to get a clearer understanding of the overall system. Look at the figure in this slide. What does it show? A bunch of black and white dots? Given that I will tell you that it contains a system (that is an object model can be found) how would you start with looking for objects? Turn the slide around. Turn it upside down. Look at the “problem domain” from all angles. And suddenly you might experience what I would call the “gestalt experience”. You will see the application domain. Now there is no recipe for finding it. You might find a very low level object, such as an ear or you might find a high level object such as the shape of a dog. In fact, if you look carefully you will find a dalmatian dog. Once you understand that you are looking at a dog, a lot of the black and white pixels in the total figure are not part of your system and you can easily find the boundary of the system by trying to trace the outline of the Dalmatian. However, don’t be lured into thinking that this is the system you have been looking for. Always be alert that the real system might be something totally different. For example, if you turn the dog upside down, you might be able to see an eagle taking off from a river, with a poor dead victim in its claws! April 20, 2019 Requirements Engineering Tutorial

2 Guidelines for use cases (1)
Name Use a verb phrase to name the use case. The name should indicate what the user is trying to accomplish. Examples: “Request Meeting”, “Schedule Meeting” Length A use case should not exceed 2 A4 pages. If longer, use include relationships. A use case should describe a complete set of interactions. April 20, 2019 Requirements Engineering Tutorial

3 Guidelines for use cases (2)
Flow of events The active voice should be used. Steps should start either with “The Actor …” or “The System …”. The causal relationship between the steps should be clear. All flow of events should be described (not only the main flow of event). The boundaries of the system should be clear. Components external to the system are described as such. Define important terms in the glossary. Negative example: The driver arrives at the parking gate, the driver receives a ticket from the distributor, the gate is opened, the driver drives through. April 20, 2019 Requirements Engineering Tutorial

4 Guidelines for use cases (3)
Exceptions Exceptions should be attached to the step where they are detected. If an exception can occur in any step, describe it only in the exception section. Exception handling is described as flow of events. At the end of the exception handling, it should be clear what happens next (if the use case is terminated or if it is resumed in a particular step). Preconditions If a case is excluded with a precondition, then it should not be handled as an exception. April 20, 2019 Requirements Engineering Tutorial

5 Guidelines for use cases (4)
Write one high-level use case per user task If a use case includes only one or two steps, it should probably be a service, not a use case. If a sequence of steps is identical in several use cases, it should be factored out into a separate use case and included in the original use cases (eliminate redundancy). <<user task>> <<use case>> April 20, 2019 Requirements Engineering Tutorial

6 General guidelines: Use Rationale (1)
Question: Which restrictions are possible? References: Service: Set restrictions Decision: Buddy list + single persons Criteria 1: Flexibility Criteria 2: User Friendliness Opt. 1: Buddy list + Opt. 2: Single persons + Opt. 3: Buddy list + single persons + April 20, 2019 Requirements Engineering Tutorial

7 Requirements Engineering Tutorial
Use Rationale (2) Questions can be used to: Request a clarification How can a Player restrict a game to her/his buddy list? Indicate a defect Isn’t a second game mode missing? Justify a use case or Which solution is the best? service Questions are asked during review and consolidated into justifications during revisions. April 20, 2019 Requirements Engineering Tutorial


Download ppt "Requirements Engineering Tutorial"

Similar presentations


Ads by Google