Use Cases

22679 Views
14 Likes
9 Comments

This article proposes a use case best practice technique: Always document decisions separately and explicitly in use case scenarios. This practice assists the business analyst in identifying where alternate and exception paths may be needed.This is similar to how decisions and resulting gateways are documented in Business Process Model and Notation (BPMN).

43141 Views
38 Likes
1 Comments

This article is all about putting your systems analysis into context; literally and metaphorically. It’s all about drawing and interpreting the not-quite-UML Context Diagram that is sometimes referred to as the System Context Diagram.

32533 Views
26 Likes
1 Comments

Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases.

75103 Views
125 Likes
7 Comments

The structure of business analysis documents isn't a commonly discussed topic. This article will show what documents are produced by a BA and the main sections they contain.

These are the main documents produced by a BA over the course of a project...
 

89969 Views
49 Likes
28 Comments

There is much written today about separating business rules from other dimensions of automated business systems. Without proper separation, they operate in enterprises without a great deal of thought given to them. Ironically, they may be the most important dimension because they represent important business thinking behind processes, use cases, for example. This article discusses various approaches for dealing with business rules and use cases.
 

21495 Views
19 Likes
10 Comments

Some people use them. Some people don't use them. Some people create them using sophisticated tools. Some use basic drawing programs. As part of the Unified Modeling Language, Use Case diagrams are often the starting point for many software projects. However, questions about Use Case diagrams still linger in the minds of many Business Analysts...

20208 Views
14 Likes
2 Comments

Have you ever thought the following thought while describing business processes? A decent percentage of the work business analysts (BAs) do is repetitive in nature. Business rules define the various subject matters, different businesses, or just differences in doing business. Just recently, I have again used a use case approach to a business process reengineering (BPR) problem. The aim was restructuring along natural business module borders, so that different applications (new and existing ones) can handle the business process more efficiently, more secure and within the right stakeholder's responsibilities. As almost always, documentation of the business processes had undergone aging as well.

15759 Views
7 Likes
0 Comments

In this article, I'll be discussing some other requirements gathering methods that complement use case modeling and should be used to ensure your requirements gathering goes swimmingly.

In particular, I'll be mentioning storyboards, wireframes and prototypes.
I'll also cover what level of quality and detail you should adopt when applying these techniques.

24942 Views
30 Likes
2 Comments

“Where does UML fit?” is a common question among new (and not so new!) business analysts. We all know that the M stands for modelling but beyond this, perceptions start to differ. In its current form (V2.0) UML consists of 13 diagram types all of which provide a different view of a system.

In this article we’ll take a brief look at which of the 13 diagrams are of most relevance for us and how they fit together...

Author: Jan Kusiak

5940 Views
2 Likes
0 Comments

The real world is a complex place, resulting in complex requirements for any system that has to work there. This is true regardless of development paradigm. Although "agile in the small" methodologies such as Scrum and Extreme Programming (XP) have done much to show us how to improve our approach, too many people have thrown out the requirements management baby with the bureaucracy bathwater after putting too much faith in the overly simplistic strategies of those processes. Luckily, with a bit of discipline, it is straightforward to address the inherent challenges of complex requirements in an agile manner without resorting to the documentation-heavy practices favored by the traditional community.

The Scrum method has popularized the idea of managing requirements as a stack of small, functional chunks, captured in a prioritized stack called a "product backlog". The idea is that at the beginning of each iteration/sprint, you pull an iteration's worth of work off the top of the stack. If only it were that easy. Although Scrum has helped us to get away from the onerous change prevention strategies (oops, I mean change management strategies) of traditional methods, it has blinded a generation of developers to the inherent complexities and nuances of understanding and implementing requirements.

Author: Scott Ambler

9914 Views
3 Likes
1 Comments

One of the issues high on the agenda of many CIOs is to align IT efforts with the company’s strategic goals. But how you do trace a line of code back to the strategic goal that caused it to be written? If we’re able to do this then, and only then, can it be said that IT is aligned with the business strategy. 

5817 Views
1 Likes
0 Comments
Test organizations can realize significant gains in test quality by harnessing the power of use cases. For years, developers and business analysts have employed use case models to capture requirements. Test organizations can greatly benefit by using these same use case techniques. Well-constructed use cases provide value to testing efforts in terms...
13730 Views
3 Likes
0 Comments

A use case study is designed to describe a situation in which the program is being utilized by the end user. It will tell a story of sorts describing how the program works and the input of the user. It does not tell how the program was developed. The details of the programming are not included in the use case study. You are trying to express the concept behind the creation.

Author: Tony de Bree

7297 Views
0 Likes
0 Comments
As long as practitioners recognize that use case diagrams are optional and iconic (as opposed to schematic), they shouldn't have problems. The diagrams are useful, for example, on whiteboards as a way of sketching and framing an agenda while people are writing up and reviewing use case detail on index cards. The trouble starts, however, when pr...
15382 Views
7 Likes
0 Comments
A whitepaper written by requirements expert Ellen Gottesdiener of EBG Consulting (www.ebgconsulting.com) for IBM/Rational Software. As an analyst, you have the crucial task of defining the requirements for software that is to be built or acquired. Your task is crucial for a number of reasons. If software teams fail to define excellent requirements...
Page 2 of 3First   Previous   1  [2]  3  Next   Last   











Copyright 2006-2020 by Modern Analyst Media LLC