Rather than expecting use cases to contain all of a system’s functionality, I prefer to employ use cases to help the business analyst discover the functional requirements. That is, the use cases become a tool to reveal functionality rather than being an end requirements deliverable themselves. Users can review the use cases to validate whether a system that implemented the use cases would meet their needs. The BA can study each use case and derive the functional requirements the developer must implement to realize the use case in software. I like to store those functional requirements in a software requirements specification, although you could add them to the use case description if you prefer.
It is certainly true that use cases are a powerful technique for discovering the functional requirements for a system being developed. However, this statement suggests that use cases are the only tool needed for representing a software system’s functionality. In most cases, they aren't.
The structure that use cases provide is far superior to the nearly worthless technique of asking users “What do you want?” or “What are your requirements?” In this article I share my perspectives on when use cases work well, when they don’t, and what to do when use cases aren't a sufficient solution to the requirements problem.
A typical business function might contain several unique events each of which we want to end up as a component of a larger software application. So how do we go from a table containing textual information to a specification which a developer can use?
This article discusses Stephen King’s creative writing method and provides an example of using it in developing a use case narrative: the main scenario with alternate and exception paths. Yes, that is correct – Stephen King, the prolific writer of contemporary horror, science fiction and fantasy novels.
The purpose of this brief article is to provide a simple example on how to link and verify four models: use case, data flow diagrams, entity relationship diagrams, and state diagrams. Note the word verify, not validate. Verify in this context means that the technique is consistent and complete, not that it reflects correct requirements.
Use case models have been around for decades. Long after Information Engineering was all the rage and through object-oriented analysis and design they hung around. They threatened to disappear when Agile methods gained popularity, but here they are. Discussed, dissected, blogged about—why don’t they just go away?!
Use case diagrams are used to show the decomposition of a business problem or software solution into a set of discrete functions (the use cases) which can be enacted by or on behalf of users (the actors). In a nutshell, this diagram shows who (the actors) can do what (the use cases) when interacting with the software solution.
As the Agile movement continues to gain momentum and managing projects using Agile methods becomes more and more prolific, project professionals must become more savvy in their use of Agile methods. While the techniques and processes associated with Agile are different than those associated with Waterfall, many innovative project teams are incorporating non-Agile techniques into the Agile environment, with great success.
In writing a business requirements document (BRD), the business analyst needs to document who can access the solution (assuming software) and what data can be created, updated, read, and deleted (CRUD). In other words, a security model that a security analyst can build access profiles with the appropriate privileges. This article provides the business analyst a method for documenting a security model in the BRD based on information extracted from Use Case and Class models
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).
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.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: