Question

Use-Case Discussion

1) In what situations would the additional effort to develop use-case definitions be superior to only having functional requirements? How would the programmer/analyst benefit from the use-case approach over just having functional requirements only? How would the project manager potentially benefit?

2) Should use-case be used in all projects? Discuss why or why not?

Answer 1

Use-Case Discussion :

In software and systems engineering, a use case is a list of actions or event steps, typically defining the interactions between a role and a system, to achieve a goal. A use case analysis is the primary form for gathering usage requirements for a new software program or task to be completed. A Use-case realization describes how a particular use case is realized within the design model, in terms of collaborating objects .The Realization step sets up the framework within which an emerging system is analysed. This is where the first, most general, outline of what is required by the system is documented. It is a methodology used in system analysis to identify, clarify, and organize system requirements.

The importance of Use Cases---

Use cases have been used extensively over the past few decades. The advantages of Use cases includes:

1.For each analysis class identified in the previous step, the responsibilities of the class must be detailed clearly. This will ensure that an individual class has a task to complete for which no other class in the system will also perform. The responsibilities of the different classes should not overlap.

2.It provides solutions and answers to many questions that might pop up if we start a project unplanned.

3.It gives an overview of the roles of each and every component in the system. It will help us in defining the role of users, administrators etc.

4.The use case should contain all system activities that have significance to the users.

Having your Software Requirement Specification captured in the form of Use Case Specifications and a Supplementary Specification, there are several additional benefits for Project Management. Since we are defining the functional requirements in terms of Use Cases, we are effectively breaking down the system into smaller parts in terms of functional decomposition. While this does not mean that all functionality will be exclusive to a particular Use Case (some functionality, or rather some implementations of functionality, might be shared across Use Cases), it certain lends itself to parallel development for disparate pieces of functionality. This is especially true if we refrain from thinking of development as the same thing as coding! For example, it’s possible for our systems analysts and test writers to work on the same Use Case simultaneously. It is also possible that while designers are evolving the results of analysis for a particular Use Case, the analysts could be working on another one. And while the designers are coming up with the designs for one Use Case, programmers could be implementing another one that has already been through the design phase. Essentially, the very act of decomposing the project into smaller parts based on functionality lends itself to exploiting opportunities for parallel development.

Discussion about Should use-case be used in all projects why or why not---

There are many textbook definitions of the term ‘use case.’ Many of these definitions are theoretical, and describe the use case in terms that are hard for the business to understand. For example, Geri Schneider defines a use case as “behavior of the system that produces a measurable result of value to an actor”. Frank Armour describes a use case as “a sequence of actions required of the system…a functional stripe through the system and is shown as a horizontal ellipse…”. Ivar Jacobson defines a use case as “description of a set of sequences of actions and variants that a system performs that yield an observable result of value to an actor.”.Martin Fowler defines a use case as “a set of scenarios tied together by a common business goal”.Simply put, a use case is a description of all the ways an end-user wants to “use” a system. These “uses” are like requests of the system, and use cases describe what that system does in response to such requests. In other words, use cases describe the conversation between a system and its user, known as actors. Although the system is usually automated, use cases also apply to equipment, devices, or business processes.Let's use the example of a microwave. There are many ways we, the actors or end-users, want to make use of the microwave, including heating up leftovers, boiling water for tea, defrosting frozen food, cooking a meal. Each one of these is a ‘use’ of the microwave and can be described in a use case. If we want to boil water for tea, we tell the microwave what we want done . The microwave boils the water and notifies us when it's done.Let's take another example, that of an automated order system. Some of the uses of that system may be to choose an item, or check the availability of the item. Other uses include creating orders, copying or moving them, and deleting them. Use cases would describe each of these system functions.

Collaborative effort enhances the success of any team. As the team members work to describe business processes, use cases provide a repository of team members' business knowledge. As a written document, each use case spawns meaningful discussion within the group. The axiom, "the whole is greater than the sum of the parts", applies here. Group discussion exposes in-depth viewpoints that would otherwise remain hidden. With use cases, the team captures these perspectives while identifying the related business goals, conditions, and issues. The result is a comprehensive and meaningful story about each business process.

The process of writing and revising use cases produces three important outcomes in the analysis team — clarity, consensus, and commitment. Remarkably, it is common for stakeholders to be uncertain about how a process they own actually works! Writing a use case helps stakeholders align the narrative with the details of an existing process.