What are user stories? Are they similar to use cases? Where is user stories used?

You must have heard about the term “user stories” and “use cases” when it comes to the discussion regarding the issues of the software development! In this article we have taken up 3 important questions to discuss as mentioned below:

1. What are user stories?
2. Are they similar to use cases?
3. Where are the user stories used?

What are User Stories?

- User story is a common term that is quite involved with everything that happens in the field of software development and the product management. 

- A user story is more like the business or every day language of the end user (end user is the one who uses the software system or application) which indicates about the activities of the user and what things he/ she needs to do to perform his part of function well.

- User stories have become quite famous.

- User stories are commonly used with the agile software development methodologies when compared its use with the other software development methodologies. 

- Actually, the user stories when used with the agile software development methodologies, serve as a basis or criteria for defining the business functions that a business system is ought to provide. 

- The facilitation of the requirements management is also done with the help of the user stories.

- There are 3 aspects of the requirements that are captured by a typical user story in a way that is quite simple and concise and with a limited description:

1. Who?
2. What?
3. Why?

Who is responsible for writing user stories?

- They are written by the business users as their means to have an influence on the functionalities and features of the software system or application that is being developed. 

- They may also be written by the system developers and programmers as a way to express the non functional requirements like the performance, quality and security. 

- But overall, the task of managing the user stories is taken up by the product manager and thus it is his/ her responsibility for ensuring that the user stories are captured properly. 

"Are user stories similar to use cases?”

Both these are similar to a certain extent. We shall state how! 

- The documentation of the requirements is created with the help of both the user stories and the use cases so that the documentation has a perspective of the user. 

- Since both of them are used in the documentation of the requirements, they both indeed help in capturing the features and functionality of the system. 

- Together they help the development to come with the best solution to the problem. 

- Another advantage of these two is that both can be used to organize the requirements of the system under different categories. 

- They also serve as a reference during the testing phase which ensures that the requirements have been met. 

But there are many other substantial ways in which they differ. 

- Without user stories the developers would have to create formalized requirements documents and perform many tasks to manage them. 

- The user stories are intended to make the response of the developers faster to the rapidly changing requirements of the users and so cutting down the overhead.

- User stories are accompanied by acceptance tests whereas use cases can be delivered as a stand alone document.

- User stories contain little detail whereas use cases include detailed description.

Where are user stories used?

- User stories are an important part of agile development methodologies.

- They give a reason what should be built in a software project.

Phase 1 of Unified Process Life cycle - Inception

Unified process like any other process has got some phases through which the whole development process takes place. The unified process follows through the following 4 steps:

1. Inception
2. Elaboration
3. Construction and
4. Transition

Throughout this whole article we are going to discuss in detail the first phase of the unified process i.e., the inception phase. So let us a take a deep dive in to the understanding of the first phase “inception” of the project life cycle.

What is an Inception Phase

- The inception phase to say is usually short in most of the development cases but in some rare cases it can be quite lengthy. 

- But in an ideal project it is advisable to keep it short and simple other wise it will be required to divide in to much smaller iterations which in turn will be a complete waste of time.

- Furthermore a lengthy inception phase may indicate that there is an excess of up front specification which is something that is not in accordance with the principles of the unified process. - Every phase of the unified process has some pre defined goals that are needed to be satisfied in that phase itself. 

Goals defined for Inception Phase

- For inception phase the below mentioned goals have been defined:

1. To define and establish a scope for the software project.
2. To establish boundary conditions for the software project.
3. To establish a justification for developing the software system or application.
4. To outline the use cases for driving the design trade offs.
5. To outline the key requirements for the same purpose as the use cases.
6. To outline all the architectures those are to be implemented in the process.
7. To identify the associated risks.
8. To prepare a preliminary project schedule.
9. To estimate the cost of the whole software project.

When all of these mentioned goals are established then the inception phase is said to be concluded and completed. 

In short, what is inception phase is all about?

- The inception phase is all about developing a close enough vision of the software project, defining its scope and making the business case and providing an approximate estimate of the schedule and cost for the whole development project. 

- The inception phase seeks to build concurrence among all the stake holders involved in the development process on the basis of the objectives. 

- In an overall sense, the inception phase determines the feasibility of the solution that has been intended to build the software system or application. 

- In a way it helps the developers to understand what to build and risks associated with the project. - Another advantage is that the key system functionality can be easily recognized. 

- Due to some reasons the developers may be forced to have more than one iterations in the inception phase. 

- The possible reasons can be:

1. The project is so large that it is difficult to define its scope.
2. The system is unprecedented.
3. There are too many stake holders with complex relationships and competing needs.
4. Creation of proof of concept or prototype is required by the major technical risks involved.

- Over the inception phase sometimes counter productive patterns are observed. 

- In such situation a team may postpone providing estimate until the whole domain has been analyzed and documented. 

- But such behavior can lead to a condition called “analysis paralysis”. 

- Even the poor planning of the iterations of the inception phase can make the whole process go awry. 

- This can be avoided only if the iterations have been planned in such a way that they are risk driven and have been integrated and tested earlier. 

What are the different attributes of the use cases?

Use cases sound similar to test cases. But the two are not same. Where the test cases are used in software testing, the use cases are used in the general software systems engineering. We have dedicated this whole article to the discussion of the use cases.

What are Use Cases?

- The use case is a set of steps which are implemented to define the interactions occurring between the software system and a role.

- This is basically done to achieve a predefined goal. The role is commonly called as an actor and can be an external software system or simply a human.

- The use cases are often used at the higher levels of the software systems engineering.

- The goals to achieve for which the use cases are developed are often defined by the stake holders.

- The requirements are stated by the stake holders in a separate documentation.

- This documentation serves at a contract between the two i.e., between the software developers or programmers and the stake holders or the clients.

- The structure of a use case has been a quite debated topic. Many opinions were given regarding the how the structure of a typical use case should be.

- But usually the structure defined by the Alistair Cockburn is followed. It is popularly known as the “fully dressed use case structure”.
It consists of the following aspects:

1. Title of the use case
2. Primary role
3. Goal of the use case
4. Scope
5. Level
6. Interests
7. Stake holders
8. Preconditions or requirements
9. Guarantees (both minimal and success)
10.Success scenario
11. Technology
12. Data variations
13. Extensions and
14. Related information

He gave some other many useful aspects related to the use cases like:

1. Casual use case structure
2. Design scope icon
3. Goal level icon

ROLE OF AN ACTOR

- The role of an actor in a use case is to make effective decisions and so calls for the need of good decision making ability.

- It is not necessary that an actor should always be a human. It can be a computer system also.

- Though the decisions of an actor influences the whole use case implementation, there does not exist any direct link between the system and the actor.

ATTRIBUTES OF USE CASES

- Certain necessary attributes have been discovered so far that are needed by the use case to accomplish the goal for which it has been developed.

- The attributes need not be only functions; they can be in the form of data variables also.

- Not all the attributes have been extracted from the preceding steps; some have been taken as the general assumptions out of common knowledge of the use cases.

1. System requirements: These requirements form the basis for thedelopmnt of a use case.
2. The requirements need to be complete and correct and of quality.
3. Software requirements specification testing
4. User- centred approach for the specification of the requirements.
5. Unified modelling language: this language based on the object oriented paradigm is employed for the construction, visualization and documentation of the system.
6. Use case diagrams

The below mentioned are the three attributes of the use cases:

1. Level of validity
This attribute is concerned with the validation of the use cases. It queries about the completeness of the use case, achievement of the goals, changes to be made, addressing of the additional goals and representation of the additional actors and so on.

2. Metrics
This use case attribute deals with the factors like the ambiguity, completeness, trace-ability and volatility of the use case.

3. Risk indicators
Typical 3 risk indicators have been identified namely incompleteness, options and weak phrases.

How to test software requirements specification?

Software requirements specifications is often called “SRS” in its short form. We
can simply put it as a specific requirement for a software system or application.

PURPOSE OF SOFTWARE REQUIREMENTS SPECIFICATION

- These requirements specifications give a view of how exactly the system should and how it should behave.
- The software requirements specification comes with a set of cases describing all the possible interactions of the users with the software system or application.
- Such test cases have been termed as ‘use cases”.
- The software requirements specifications contains both kinds of requirements i.e., functional requirements as well as non functional requirements.
- Software requirements specification is an important sub field under the software engineering field.
- The software requirement specification provides a way to enlist all the requirements necessary for the development of the software project in one place.
- It deals with the following issues with regard to the software system or application:


1. Specification
2. Elicitation
3. Analysis and
4. Validation


OVERVIEW OF SOFTWARE REQUIREMENT SPECIFICATION

1.Introduction
This mentions the purpose of the software along with its scope, definitions, a brief overview and a set of references.

2.Overall Description
This section of the SRS describes the perspective, functions, user characteristics, constraints, dependencies and assumptions of the software application.

3. Specific Requirements
This is the most important part of an SRS and includes description of functions, interfaces, logical data base requirements, performance requirements, design constraints and key features.

HOW TO PRODUCE AN EFFECTIVE SOFTWARE REQUIREMENTS SPECIFICATION?

- For producing an effective software requirements specification, you need to test it.
- Therefore a software requirements specification testing has been designed.
- It is popularly known as requirements analysis.
- Requirements analysis analyzes all those tasks that help in identifying the requirement specifications of the software system as well as the requirements specifications itself.
- This actually forms the initial stage of the requirements engineering which is again concerned with the above listed activities.
- The analysis of the requirements specification is crucial for any software system or application.
- All the identified requirements should have the following properties:


1.Actionable
2.Can be documented
3.Testable
4.Traceable
5.Measurable and
6.Defined


PHASES OF SOFTWARE REQUIREMENTS SPECIFICATION TESTING
The software requirements specification testing comprises of the following three phases:

#1. Elicitation of the Requirements:
- This phase involves the identification of the requirements of the consumers.
- This process of communicating with the users and gathering requirements is very well known as requirements gathering.

#2. Analysis of the Requirements:
- This phase involves the determination of the clarity, completeness, ambiguity, contradiction of the requirements.
- If issues are found, they are resolved.

#3. Recording of the Requirements
- There are various ways in which the requirements might be documented.
- Whatever the way maybe, it should be clear and concise.
- Some commonly used methods are: natural language documents, user stories, process specifications and use cases.

Estimation techniques - estimation using use cases

We have read about estimation techniques like problem and process based estimation techniques. There is another estimation approach that uses use cases which provide insight into software scope and requirements. However, it is somewhat difficult to develop an estimation technique using use cases.

- There is no standard format or style in which use cases can be described because there are many different formats and styles that a use case can use.
- The complexity of the functions are not addressed by the use cases.
- Complex behavior like interactions among many functions and features are not described by the use cases.
- Use cases are used to represent the user's view of the software.

Use case estimation technique for one person can require a lot of effort while use case estimation technique for some other person can be done in a day or two. According to Smith, use cases can be used for estimation but it is only possible and considered within the context of structural hierarchy that the use case describe.

- structural hierarchy can have not more than 10 use cases.
- each use case can have not more than 30 different scenarios.
- before using use case estimation, level within structural hierarchy is established, average length of each use case is computed, type of software is defined, rough architecture is considered.
- empirical data is used to establish lines of code or function point for each level.

What is the task set for project planning? What is software scope and feasibility?

Steps that are involved for project planning are:
- Establish a project scope.
- Determine the feasibility.
- Analyze the risks.
- Define the required resources like human resources required, reusable software resources and environmental resources.
- Estimate the cost and effort by decomposing the problem, developing two or more estimates using size, function points, process tasks or use cases and reconciling the estimates.
- Developing a project schedule which includes establishing a meaningful task set, defining a task network, using scheduling tools to develop a timeline chart and defining a schedule for tracking mechanisms.

Software scope are functions and features that are delivered to end users, input and output data, content that is presented to users and the performance, constraints, interfaces and reliability that bound the system. Using either of the two techniques are used to define scope:
- set of use cases developed by end users.
- narrative description of software scope developed after communication with stakeholders.

Project feasibility is important but a consideration of business need is even more important. It does no good to build a high tech system or product that no one wants.

What is meant by Use-case oriented metrics?

Using the use case method is not dependent on the programming language. Typically, you can use use cases as another method of generating the size of the application; the value of use cases is in most cases to the lines of code (LOC) and also to the number of test cases that will have to be written for comprehensive testing of the application. Like many other estimation techniques, the use case method is used early in the software life cycle, before design, development and testing happens.

A use case is written to capture user interactions and functions that describe a system. Many users try to work out what a standard size for a use case is, but use cases can exist at different levels of abstraction. As a result, though there are many attempts to use the use case method as a instrument of trying to measure the effort required for building the application, the inability to define a size and coverage of the use case, means that not many people have been successfully able to do this.

Estimation through use case method is not a simple one; there are multiple steps required such as determining technical factors, determining environmental factors, determining use case points, determining product factors, and then overall, putting all these factors together to get use case points which translate into man-days or man-weeks.

What is Requirement Analysis for Web Applications?

Requirement analysis for web applications consists of formulation, requirement gathering and analysis modeling.
- In formulation, goals and objectives and categories of users for web application are identified.
- In requirement gathering, communication between web engineering team and stakeholders deepens.
- In analysis modeling, content and functional requirements are listed and interaction scenarios are developed.

USER HIERARCHY
It is a good idea to build a user hierarchy. It provides you with a snapshot of user population and a cross check to help ensure that the needs of every user have been addressed. End-user categories interacting with web application are identified. As the number of user categories increases, developing a user hierarchy is advised. User categories provides an indication of functionality provided by WebApp and indicate need of use cases to be developed for each end-user in hierarchy.

DEVELOPING USE CASES
For each user category, use cases are developed which is described in user hierarchy. A use case is relatively informal i.e. a narrative paragraph that describes a specific interaction between user and web application. As the size of web application grows and analysis modeling becomes more rigorous, the preliminary use cases presented would have to be expanded to conform.

REFINING USE CASE MODEL
Use cases are organized into functional packages and each package is assessed to ensure that it is comprehensible, cohesive, loosely coupled and hierarchically shallow. The new use cases will be added to packages that have been defined, existing use cases will be refined and specific use cases might be reallocated to different packages.

How to create a behavioral model in software engineering?

While other analysis modeling elements provides a static view of the software, behavioral modeling depicts the dynamic behavior. The behavioral model uses input from scenario based, flow oriented and class based elements to represent the states of analysis classes and the system as a whole. To accomplish this, states are identified, the events that cause a class to make a transition from one state to another are defined, and the actions that occur as transition is accomplished are also identified. State diagrams and sequence diagrams are the UML notation used for behavioral modeling.

The behavioral model is an indication showing how a software responds to external event. Steps to be followed are:
- All use cases are evaluated.
- Events are identified and their relation to classes are identified.
An event occurs whenever the system and an user exchange information. An event is not the information that is exchanged but a fact that information has been exchanged.

- A sequence is created for use-case.
- A state diagram is built.
There are two different characterizations of states in behavioral modeling : state of class as system performs its function and the state of the system as seen from outside. The system has states that represent specific externally observable behavior whereas a class has states that represent its behavior as the system performs its functions.
- Behavioral model is reviewed for accuracy and consistency.

What are steps involved in deriving test cases? What are Validation, Alpha, Beta testing? What are test metrics?

The steps in deriving the test cases using use cases are:
- Using the RTM, the use cases are prioritized. Importance is gauged based on the frequency with which each function of the system is used.
- Use case scenarios are developed for each use case. The detailed description for each use case scenario can be very helpful in later stage.
- For each scenario, take at least one test case and identify the conditions that
will make it execute.
- Data values are determined for each test case.

After system testing is culminated, validation testing is performed which consists of a series of black box tests. It focuses on user-visible actions and user-recognizable output.
Alpha and Beta Testing are a series of acceptance tests. Alpha testing is performed in a controlled environment normally at developer's site. In alpha testing, developers record all errors and usage problems while end users use the system. Beta testing is done at customer's site and developers are not present. In beta testing, end-users records all errors and usage problems.

The amount of testing effort needed to test object oriented software can be indicated by the metrics used for object-oriented design quality. These metrics are:
- Lack of Cohesion in Methods (LCOM)
- Percent Public and Protected (PAP)
- Public Access To Data Members (PAD)
- Number of Root Classes (NOR)
- Number of Children (NOC) and Depth of the Inheritance Tree (DIT)

What is Test Driven Development Methodology and its benefits?

Test-driven Development(TDD)is a method of developing software that adopts a test
first approach plus refactoring. The test-first approach is a programming technique, involving analysis, design, coding and testing all together. Refactoring is used to improve the design of the code without changing the observable behavior of the software, it changes the internal structure. It is cleaning up the bad code. In test-driven development, each new test provides feedback into the design process which helps in driving design decisions.

WHAT ARE DIFFERENT BENEFITS OF TEST DRIVEN DEVELOPMENT

- It allows simple incremental development.
- It involves a simpler development process.
- It provides constant regression testing.
- It improves communication.
- It improves understanding of required software behavior.
- It centralizes knowledge.
- It improves software design.

WHAT ARE DIFFERENT STEPS IN TEST DRIVEN DEVELOPMENT

- Write a test that defines how the software should behave.
- Make the test run as easily and quickly as possible.
- Clean up the code.

After integration testing, the system is tested as a whole for functionality and fitness of use. It includes performance testing, stress testing, security testing, recovery testing.
In object oriented, test requirements are derived from analysis artifacts or work products that use UML such as the class diagrams,sequence diagrams and collaboration diagrams. Use case diagram is a good source to derive test cases. They represent high functionality. Use cases are not independent. They have sequential dependencies. A scenario is an instance of a use case, or a complete path through the use case.

Requirement Model - Obtained during Elaboration phase

During elaboration, the information that is obtained from inception and elicitation are refined and expanded to produce two models:
- Requirements Model
- Analysis Model

The requirement model provides a model of the system or problem domain. It consists of three things:

Use Case Model
Use case model describes what the system does. It serves as a contract between the customers, end users and developers. The Use CaseModel consists of two parts, namely, the use case diagrams and use case specifications.
The use case diagram shows the functionality that the system provides and which users will communicate with the system. It consists of actors and use cases.
The use case specifications are textual documents that specify properties of the use cases.

Supplementary Specifications
Requirements that do not map to a specific use case are part of supplementary specifications. These requirements may be non functional or system constraints. Non functional requirements includes maintainability of the source codes, usability, reliability, performance, and supportability. System constraints restricts our choices for constructing a solution.

Glossary
It defines a common terminology for all models. This is used by the developers to establish a common dialect with customers and end-users.

Introduction to Unified Process - Different stages in Unified Process

The Unified Process is a use-case driven, architecture-centric, iterative and incremental software process designed as a framework for UML methods and tools. The Unified Process is an incremental model in which five phases are identified:

- Inception Phase
It encompasses both customer communication and planning activities and emphasizes the development and refinement of use cases as a primary model. Incremental nature of the ensuing project is developed. In general, a use-case describes a sequence of actions that are performed by an actor as the actor interacts with software.

- Elaboration Phase
It encompasses the customer communication and modeling activities focusing on the creation of analysis and design models with an emphasis on class definitions and architectural representations. Elaboration refines and expands the preliminary use cases that were developed as part of inception phase and expands the architectural representation to include five different views of software - use case model, analysis model, design model, implementation model and deployment model.

- Construction Phase
It refines and then translates the design model into implemented software components. To accomplish this, analysis and design models started during elaboration phase are completed to reflect the final version of software increment.

- Transition Phase
It transfers the software from the developer to the end user for beta testing and acceptance. The software team creates the necessary support information that is required for release. At the end of this phase, the software increment becomes a reusable software release.

- Production Phase
In this, it is an on-going monitoring and support are conducted. This phase coincides with the deployment activity of generic process.

It is possible that work may have already begun on next software increment at the same time when the construction, transition, and production phases are conducted.

Overview of The Interaction Model - Use cases, Sequence diagrams, State diagrams, User interface prototype

The interaction model of web applications enables a conversation between an end user and application functionality, content, and behavior. Interaction model is made up of four elements:
- Use cases
- Sequence diagrams
- State diagrams
- User interface prototype

Some use cases describe the interactions between end user categories and the system. Other use cases refine the interactions, providing the analysis detail necessary to guide design and construction. Use cases provide a one-dimensional view of the interaction.

Sequence diagrams are a shorthand representation of the manner in which dynamic elements(user actions) collaborate with the structural elements(analysis classes) of the system. There is a need to ensure that traceability exists between the classes that have been defined and the use-cases that describe system interaction. Sequence diagrams can be created for each use-case once analysis classes are defined for the use case. Sequence diagrams present a second dimension that is more procedural in nature.

As the interaction occurs, state diagrams are another way to represent the dynamic behavior of the web application. State diagrams can be represented at different levels of abstraction. State diagrams provide a third dimension that is more behavioral and contains information about potential navigation pathways that is not provided by use cases or the sequence diagram.
Large complex web applications benefits from interaction model that encompasses the three representations : use cases, sequence diagrams and state diagrams.


User Interface Prototype : The layout of user interface, content it presents, interaction mechanisms, and overall aesthetic of user-web application connections have much to do with user satisfaction and the overall acceptance of the web application. User interface prototype is performed during the creation of analysis model.

Overview of The Content Model for Web Applications

The content model is derived from an examination of use cases developed for the web application. This model contains structural elements that provides a view of content requirements for a web application. Structural elements include content objects like text, images, audio, video and photographs.It also contains analysis classes which cover attributes that describe it, operations that effect the behavior and collaborations.

A content object is any item of cohesive information that is to be presented to an end-user. These content objects are extracted from use cases. Content can be developed before the web application implementation, while the web application is being built or long after web application is operational.
The web engineer meets the person who has designed the use case and obtain a more detailed understanding of what descriptive and pricing information means. The descriptive information includes a paragraph of general description of component, photograph of component, a multi-paragraph technical description of component, a schematic diagram of component and a thumbnail video that shows how to install the component.

Content objects with a brief description of each object is more than enough to define the requirements for content that must be designed and implemented. In some cases, a data tree is used to represent a hierarchy of content objects. The content model may contain entity relationship diagrams that describes the relationship among content objects.

Overview of analysis for Web Applications

Web application analysis focuses on the information or content that is to be presented, the functions that are to be performed for the end user and behaviors that a web application exhibits as it presents content and performs functions.

Web application analysis model is comprised of a set of UML diagrams and text that describe content, interaction, function and configuration. Analysis of web applications is done when the following conditions are met:
- Web application to be built is large and complex.
- Number of stakeholders is large.
- Number of web engineers and other contributors is large.
- Web application's goals and objectives will effect the business bottom line.
- Success of web application will have strong bearing on the success of business.

Requirement analysis consists of formulation, requirement gathering and analysis modeling. In formulation, goals, objectives and categories of users are defined. In requirement gathering, communication between web engineering team and web application stakeholders intensifies.
Building a user hierarchy provides with a snapshot of the user population and a cross-check to ensure that the needs of every user have been addressed.

A use case diagram is created for each user category. Use cases are organized into functional packages and each package is assessed to ensure that it is comprehensible, cohesive, loosely coupled and hierarchically shallow.

Requirement analysis and modelling are iterative activities, new use cases are defined and added to packages, existing use cases will be refined and that specific use cases might be reallocated to different packages.

Introduction to Navigation Design - Navigation Semantics and Syntax

Once the web application architecture and the content is defined, navigation pathways that enable users to access the web application content and functions.
- semantics of the navigation for different users of the site should be identified.
- syntax of achieving the navigation should be defined.

NAVIGATION SEMANTICS

Each user category has a user hierarchy and related use cases. There are different navigation requirements for each actor. A set of classes are defined for the use cases developed for each user. It contains one or more content objects or web application functions. As interaction with web application occurs, series of Navigation Semantic Units(NSUs) are encountered. A NSU describes the navigation requirements for each use case. The NSU shows how an actor moves between content objects or web application functions.
Navigation Semantic Unit is a set of information and related navigation structures that collaborate in the fulfillment of a subset of related user requirements.

The Web application designer creates a navigation semantic unit for each use case associated with each user role. During initial stages of navigation design, the web application content architecture is assessed to determine one or more ways of navigating for each use case. Ways of navigating identifies navigation nodes and the links that enable navigation between them.

NAVIGATION SYNTAX

The syntax of navigation design are:
- Tabs: a variation of navigation bar or column.
- Individual navigation link: test based links, icons, buttons and graphical metaphors.
- Horizontal Navigation bar: lists major content or functional categories in a bar containing appropriate links.
- Vertical Navigation column: lists major content or functional categories and second lists virtually all major content objects within web application.
- Site maps: provide an all-inclusive table of contents for navigation to all content objects and functionality contained within web application.