Large software systems have a few hundred to thousands of requirements. Neither are all requirements equal nor do the implementation teams have resources to implement all the documented requirements. There are several constraints such as limited resources, budgetary constraints, time crunch, feasibility, etc., which brings in the need to prioritize requirements.

This article provides an in depth study on the concept of traceability, together with its implications and applications within a business context. Traceability is a term used in the IIBA BABOK, among other professional practices, in the context of requirements where requirements are said to be traced that provides alignment of requirements to each other. This implies that there are different classes or abstractions of requirements such as stakeholder, business and functional requirements. Traceability allows the alignment between all types or abstractions of requirements, telling a kind of story to how they all interrelate. 

This is the eleventh in a series that explains the thinking behind the Volere requirements techniques— previous and future articles explore aspects of applying these techniques in your environment.

This article focuses on the often-asked question: why, when I ask for requirements, do people give me solutions and what can I do to get the real requirement?

This article explores the discipline of problem solving. Some might consider problem solving an art, while others might define it as science. The reality is a little in between since part of problem solving involves creativity, which by definition cannot be rationalized as science since we are basically unaware or not conscious of it occurring. Creative formulation of new concepts and ideas is a process lies deep within the sub consciousness and we are only aware of the output of the creative process; a new idea is a good example. We don’t understand how the idea was created, but we know we thought of it.

 Managers often ask me what return on investment (ROI) they can expect from the money they spend on training, process improvement, and tools for requirements engineering. I’d love to give them a nice, tidy answer—but I can’t. As with so many questions in software, the correct answer is, “It depends.” This article explores some of the factors that influence what ROI an organization can expect from better requirements.

Solution Anthropology encompasses the work of anyone who works directly with the end users so the work is coordinated and consistent. Therefore Solution Anthropology is not one role, but a team of people with the responsibility to delight the end user and a broad skill set to accomplish just that.

 They took a software approach for designing MIDAS as opposed to a system approach. For example, they probably created a data base quickly, then tried to figure how to get data in and out of it. I would suspect the program source code was well written, probably using "Agile" techniques, but the fact remains none of it was designed to work in a concerted manner.

Article describes the two modes of decision making and provides a case for the second mode to enable the decision to be validated through a set of evaluation criteria

BA needs to ensure that any process improvements benefit the end-customer – a quicker delivery, higher quality, or a less expensive product/service from the eyes of the customer. But what happens if the BA only evaluates a sub process? Can the end-customer value be harmed (i.e., slower delivery, lower quality, more expensive product or service)? 

Over the past 15 years IDIOM has conceived, evolved, and demonstrated the effectiveness of it’s ‘decision centric’ development approach, which leverages both decisioning and agile approaches to radically simplify and strengthen commercial systems development. This advertorial describes the IDIOM products and how they can be used to implement the decision centric approach.

The UML State Diagram, sometimes known as the Statechart Diagram or Static Transition Diagram, defines the entire lifecycle of a business entity or object in terms of the messages it receives and the responses it makes from the moment of creation until the moment of destruction.

Agile, formally introduced in 2001 through the Agile Manifesto, has morphed into many variations and been customized within organizational cultures and projects. After 14 years since its introduction, this article raises an important question.

Observation as a tool is used to understand people and their environments. It is a tool best used not in situations where we are verifying fairly well-understood information, but rather in situations where we do not really know what we are looking for. Observation is not about validating assumptions, but rather is a tool to find out what we don’t know that we don’t know. Observation should bring out the surprising and the unexpected. Of course observation has a purpose. But the purpose can be fairly broad.

The primary subject of this article is process, a word that is generally both indefinite and nuanced when applied to systems development. In this article we describe how process as a concept becomes both simpler and more definitive when it is integrated with decisioning. The combination of process and decisioning extends the ‘decision centric’ development concepts that we have evolved over the last 15 years. These concepts combine into a proven, practical, and robust methodology that leverages decisioning and agile techniques to fundamentally simplify commercial software development.

My purpose in writing this brief article is to give some quick insight into the BABOK V3 which, by the way, is near twice the page volume when compared to V2. Obviously, V3 requires a perusal rather than a quick scan. In the future, I am sure to reference V3 several times and gain further insight in different contexts. It is worth the read.