Process Flows are usually used for user facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic. When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.
To ensure the continuity of operational business knowledge, no organization should ever depend on absent brains – or even on brains that could (and eventually always will) become absent in the future. To say it differently, your operational business knowledge should be encoded explicitly in a form that workers you have never even met yet can understand.
Business analysis is an indispensable function in all business organizations, performed at myriad forms and scales. Maintaining high quality of business analysis consistently is a challenge to many organizations. Inconsistent business analysis output quality results in undesirable project outcomes, poor decisions, operational disjoints and missed opportunities. This article uses an actual case to discuss how low quality business analysis impacts an organization and what improvement initiatives the organization implemented to address the problems.
Most discussions about software requirements deal with business information systems and similar projects. The world is also full of products that use software to control hardware devices, broadly called embedded systems. Among countless examples are cell phones, television remote controls, kiosks of all sorts, Internet routers, and robot cars. This is the first article of two that will discuss some of the requirements issues that are especially important to embedded and other real-time systems.
Given the right circumstances, even good people can go astray as our psychology push us down the slippery slope of questionable behavior. A little bit of knowledge about the forces that drive us to cheat can go a long way helping avoid bad behavior. Here are some common landmines to become aware of so you can make sure to defuse them as you embark in a new BA project
The problem with many Unified Modeling Language (UML) educational texts is that they present the various concepts each in isolation; so you see a use case diagram for one problem domain, a class diagram for an entirely different problem domain, and you never get to see the important traceability between the diagrams.
In this case study we aim to put it right by working through a single problem from use cases and activity diagrams, through sequence diagrams and state diagrams, to class diagrams and component diagrams. We have arranged the case study as three distinct perspectives or aspects as follows.
The context diagram and the use case diagram are two useful techniques for representing scope. This article describes two other methods for documenting scope: feature levels and system events.
With the rise in popularity of agile methods, business analysts and product owners often use the term “agile requirements” to label their work. We do not care for the term “agile requirements” because it implies that the requirements for an agile project are somehow qualitatively different from those for projects following other life cycles. A developer needs to know the same information to be able to correctly implement the right functionality regardless of the life cycle being used.
brought to you by enabling practitioners & organizations to achieve their goals using:
Advertising Opportunities | Contact Us