35. Actor-Goal List L Find unfinished task and reject it Reject unfinished task Support H Receive request and approve it Approve Request Approver H Make change in edit group and send it Submit Change Request Requestor Prio Brief Descriptions Goals Actor
discuss background, and explain about segments and at the end of each segments I will pause for any discussions
Here is how we visualize a software project
Typical software projects spend roughly one-third of their overall budget correcting errors that originate in requirements project stakeholders such as clients, end users, develoeprs, testers and managers Years of experience led to development of a number of techniques and models to assist the process Use case model is the most well-known
You might say that this is more for the IT folks, that is not completely true. Example is IDEO story. How innovation is produced from multidiscipline cooperation You will also be involved from .
To understand Use Case, first let’s take a look at Requirements. Requirements are the defined operational capabilities of a system or process that must exist to satisfy a business need. User requirements: tasks that users need to achieve using the software.
Requirements don’t come out of thin air. They are products of systematic discovery and definition process where analyst plays a key role. Software requirements came from process of thinking through three perspectives of requirements.
At the highest level (or business level), you begin by understanding and clarifying the business’ goals and objectives. Then you define the vision on how to achieve it. You ensure that you will build the right software. In addition, you also define the correct project stakeholders.
This is where use cases come in. Use cases is the interaction between an external actor and the system
Technical requirements include functional requirements based on user requirements and nonfunctional requirements
Use cases are fundamentally a text form. The scenario describes how the system should respond to a request of a primary actor to deliver a specific goal of that actor.
(bullet points first) Incidentally actor can be a person, job title or a thing, although generally it is a role The SuD is also an actor.
A scenario describes a sequence of steps that are executed in order to fulfill the goal the use case is supposed to deliver.
We just discussed about some of the use cases components, now we’ll look into the detail of different properties of the each use case
There are different scope depends on the type of use cases
From Alistair Cockburn.
How do we develop use cases
example is shown in the table
scope creep: scope of the projects expands as the work proceeds requirements may change because of changing market and business conditions -> unavoidable manage the avoidable scope creep
The first step is to just name the use cases, and not the details
best practice on how to give a name
elicit: to draw or bring out or forth; educe; evoke: to elicit the truth; to elicit a response with a question.
This is different than the Design Scope
trigger: customer wants money, responses: ATM gave out the money
a context diagram is a simple diagram that represents the system as a single ‘black box” surrounded by its major interfaces, thus showing the system in its environment.
Ensure that each one is necessary to meet the business opportunities in your product vision. To validate, answers the following questions; How does this uc help us achieve our goals and visions Does this use case address some aspect of the problem in our problem statement ? Does this use case differentiate our product in some way ? Do we have use cases to address all the stakeholder and user groups we identified in our vision statement Which use cases will be implemented in our initial release ?
A requirement model is a set of models which acts as a blueprint for a software product. Example are: event lists, use cases, context diagrams, data models, business rules, actor maps, storyboards Defining requirement is a discovery process for users and customers. It evolve from the process of users trying out their requirements through models. Using multiple views (behavior, structure, dynamics, or control ) gives a rich context for eliciting user requirements and aligns with separation of concerns.
The list is with order of increasing complexity
A man is flying in a hot air balloon and realizes he is lost. He reduces height and spots a man down below. He lowers the balloon further and shouts: "Excuse me, can you tell me where I am?" The man below says: "Yes you're in a hot air balloon, hovering 30 feet above this field." "You must be a software developer," says the balloonist. "I am," replies the man. "How did you know?" "Well," says the balloonist, "everything you have told me is technically correct, but it's of no use to anyone." The man below says, "You must work in business as a manager." "I do," replies the balloonist, "but how did you know?" "Well," says the man, "you don't know where you are or where you are going, but you expect me to be able to help. You're in the same position you were before we met but now it's my fault."
conventionally you read use case diagrams from left to right, with actors initiating use cases on the left and actors that receive use case results on the right. Also put primary actor on the top.
When use case A specializes use case B (or B generalizes A) you express that A is “a kind of” B, implying that whatever applies to B also applies to A. A adds to or may override behavior of B.
A typical example is a Summary use case that includes User Goal use cases, or User Goal use case that includes some reusable Subfunction use case. The included use case is typically not complete on its own and is required part of the larger use cases.
Karl Wieger’s Structured Requirements Software Requirements, 2nd Edition, Karl E. Wiegers .
See next screen. Formal and informal use cases describes different permutations. Use case brief may use single paragraph. User stories provides the least context. http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/comment-page-1/#comment-497898
http://tynerblain.com/blog/2009/02/02/user-stories-and-use-cases/ Use case briefs may be a single paragraph use case
User stories, as it has less overhead of documentation, it also captures less detail. It is ok with assumption the communication is high. At some point it becomes inefficient.
The level of conversation will be influenced by the level of the reader domain expertise. If the reader already understand the requirements, user stories might be enough. When the developer team struggles to implement the stories, then a more structured documentation is needed. Can the writer trust the reader will understand with brief information ?