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. Plan-Based : capturing all requirements up-front, focus on Use Cases . Agile : Iterative refinement, stronger focus on User Stories . In this course we will cover both techniques! 2 / 28
Textual Analsis 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
User Stories 4 / 28
User Stories 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 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. 1. Who - the role of users. 2. What - the goal what that class of users wants to achieve. 3. Why - the benefit why the users want to achieve that goal . 6 / 28
User Stories 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
User Stories Conversation The details of a requirement are exposed and communicated in a conversation among the development team, customer and stakeholders. 8 / 28
User Stories Confirmation A user story also contains confirmation information in the form of conditions of satisfaction . These are acceptance criteria that clarify the desired behaviour. Conditions of satisfaction are generally put on the back of the card describing a user story. 9 / 28
User Stories Definition User stories form an abstraction hierarchy and are refined progressively . 10 / 28
User Stories 1. Epics form the initial level, take months to finish, too big for even a single release. They are development initiatives intended to deliver the value of an investment theme and are identified, prioritized, estimated, and maintained in the portfolio backlog . 2. Features are refined and broken down epics, would take weeks to finish and are therefore too big for a single sprint. 3. Stories (also called sprintable stories) are refined and broken down features and fit into a sprint. 4. Tasks are descriptions of how to build a story, and generally concerned with technical and implementation detail. 11 / 28
User Stories Definition Use INVEST for evaluating whether stories are fit for their intended use: Independent, Negotiable, Valuable, Estimatable, Small, Testable 1. Independent : loose coupling between stories. 2. Negotiable : leave room for the customer, stakeholders and the development team to negotiate details. 3. Valuable : present some value to customers and users. 4. Estimatable : can be estimated by the team, providing an indication of its size and therefore the effort and cost of the story. 5. Small : can be finished in a sprint without the risk of not being able to finished due to its size. 6. Testable : should be testable in a binary way: they either pass or fail their associated (acceptance) tests. 12 / 28
User Stories 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. 1. Set of statements, each with a clear pass/fail result. 2. Defining the boundary of a story and to understand it better. 3. Specify both functional and nonfunctional requirements. 4. Applicable at a variety of levels (epics and user stories). 5. Focus on business intent rather than detailing a solution. 6. Describing what the team wants to accomplish, not how . 13 / 28
Use Cases 14 / 28
Use Cases 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
Use Cases Figure: Gazelle 16 / 28
Use Cases Figure: Gazebo 17 / 28
Use Cases 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
Use Cases 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
Use Cases 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 service. It is often an external computer system but could also be an organisation or person. Identified to clarify external interfaces and protocols. 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
Use Cases 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. 1. Start by going through the Main Success Scenario describing it as a sequence of numbered steps. 2. Other scenarios, for example failure, exceptional situations or alternative ways, are expressed in an Extensions block. 3. Each use case has a primary actor which is generally the initiator of the use case and is the actor the use case is trying to satsify. 21 / 28
Use Cases Use Case Name: Buy a Product Primary Actor: Shop visitor Main Success Scenario: 1. Customer browses catalog and selects items to buy 2. Customer goes to check out 3. Customer fills in shipping information 4. System presents full pricing information, including shipping 5. Customer fills in credit card information 6. System authorizes purchase 7. System confirms sale immediately 8. System sends confirming e-mail to customer 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
Use Cases 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 out the step. 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
Use Cases 24 / 28
Use Cases A full Use Case: https://homepages.fhv.at/thjo/lecturenotes/sysan/textual-analysis. html#content 25 / 28
Use Cases 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
Use Cases Finding Use Cases: 1. Chose the system boundary . 2. Identify the primary actors . 3. Identify the goals for each primary actor. 4. Define use cases that satisfy user goals and name them according to their goal. 5. Outline the flow of the use cases to start to gain an understanding of required 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. 6. Refine the use cases to another level of detail or perhaps the team will move directly to the stories that implement the use case. 27 / 28
Use Cases 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
Recommend
More recommend
