System Analysis Chapter 3: Textual Modeling Jonathan Thaler - - PowerPoint PPT Presentation
System Analysis Chapter 3: Textual Modeling Jonathan Thaler Department of Computer Science 1 / 28 Textual Analsis Before modeling of the domain can start it needs to be clear to some extent what the project is actually going to implement.
Jonathan Thaler
Department of Computer Science
1 / 28
Before modeling of the domain can start it needs to be clear to some extent what the project is actually going to implement. Plan-Based: capturing all requirements up-front, focus on Use Cases. Agile: Iterative refinement, stronger focus on User Stories.
2 / 28
Envisioning The goal of envisioning is to expound upon an initial idea or product vision, describing the essence of the potential product and creating a rough plan for how to approach its creation. Start: idea, which survives the organisational filters. How: low ceremony, ongoing activity, spend not too much time. Initially: create enough understanding for a minimal first release. Participants: customer, internal stakeholders, development team, other specialists (marketing, UX, system architecture). Outcome: initial product backlog with high-level User Stories (aka Epics).
3 / 28
4 / 28
Definition User stories are a format of expressing the desired business value of features. Understandable to both the customer and developers . Structurally simple. Provide a placeholder for a conversation. Can be written at various levels of granularity. Easy to refine progressively. Characterised by three Cs: card, conversation and confirmation.
5 / 28
User stories are written on small index cards or sticky notes: Card It serves as the placeholder for more detailed discussions that will take place among the stakeholders, customer and development team.
6 / 28
Definition Each card comes with a title and contains a sentence of the structure: As a <user role> I want to <goal> so that <benefit>.
7 / 28
Conversation The details of a requirement are exposed and communicated in a conversation among the development team, customer and stakeholders.
8 / 28
Confirmation A user story also contains confirmation information in the form of conditions of
Conditions of satisfaction are generally put on the back of the card describing a user story.
9 / 28
Definition User stories form an abstraction hierarchy and are refined progressively.
10 / 28
investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog.
therefore too big for a single sprint.
fit into a sprint.
technical and implementation detail.
11 / 28
Definition Use INVEST for evaluating whether stories are fit for their intended use: Independent, Negotiable, Valuable, Estimatable, Small, Testable
team to negotiate details.
and therefore the effort and cost of the story.
due to its size.
associated (acceptance) tests.
12 / 28
Definition Acceptance criteria are the conditions that a solution must satisfy to be ac- cepted by a user, a customer, or in the case of system-level functionality, the consuming system.
13 / 28
14 / 28
User stories aren’t use cases. – Mike Cohn User stories serve the same purpose as use cases but are not the same. – ExtremeProgramming.org A user story is to a use case as a gazelle is to a gazebo. – Alistair Cockburn
15 / 28
Figure: Gazelle
16 / 28
Figure: Gazebo
17 / 28
Definition A Use Case is a description of a set of interactions between an actor and a system, producing an observable result for that actor. Can have multiple success and failure scenarios. You can think of scenarios as User Stories. Defines a contract of how a system will behave, therefore complementary to User Stories. Bridge between informal User Stories and more formal modeling.
18 / 28
Definition An actor is a role that a user plays with respect to the system. Actors carry out use cases. A single actor may perform many use cases A use case may have several actors performing it. An actor does not have to be human.
19 / 28
Primary Actor Has user goals fulfilled through using services of the system. Identified to find user goals, which drive the use cases. Supporting Actor Provides a service to the system such as an automated payment authorisation
Offstage Actor Has an interest in the behaviour of the use case, but is not primary or supporting such as a government tax agency. Identified to ensure that all necessary interests are identified and satisfied.
20 / 28
Content of Use Cases: The UML use case specification does not specify the format of writing use cases. Different formats of various levels of formality have been established.
numbered steps.
expressed in an Extensions block.
and is the actor the use case is trying to satsify.
21 / 28
Use Case Name: Buy a Product Primary Actor: Shop visitor Main Success Scenario:
Extensions: 3a: Customer is regular customer 1.: System displays current shipping, pricing, and billing information 2.: Customer may accept or override these defaults, returns to MSS at step 6 6a: System fails to authorize credit purchase 1.: Customer may reenter credit card information or may cancel
22 / 28
Each step in a use case is an element of the interaction between an actor and the system. Each step should be a simple statement and should clearly show who is carrying
The step should show the intent of the actor, not the mechanics of what the actors does. Do not describe the user interface in the use case. An extension is started by naming the step at which the condition is detected. It is possible to include or extend use cases by underlining. Do not try to break down use cases into sub-use cases and subsub-use cases.
23 / 28
24 / 28
A full Use Case: https://homepages.fhv.at/thjo/lecturenotes/sysan/textual-analysis. html#content
25 / 28
Use Case Diagrams Use cases can be expressed to a certain extent using the use case diagram. However: use cases are text documents, not diagrams, and use case modeling is primarily an act of writing text, not drawing diagrams.
26 / 28
Finding Use Cases:
system behaviour at the next level of detail. Of particular interest at this time is the flow of events, including the basic and alternate flows.
directly to the stories that implement the use case.
27 / 28
Use Cases in Agile Methods Use cases were largely banned from agile methods in favour of user stories: ”Don’t use use cases. They are too hard to write, and users dont understand them.” User stories lack context: they do not provide a mechanism for looking ahead at upcoming work and alternate flows. Extension conditions are usually detected mid-sprint, when it is too late. Use Cases have much larger scope and cover multiple User Stories. Start with User Stories, and refine complex system features into Use Cases. See Lecture Notes 3.3.5 for more details.
28 / 28