Business Architecture is about more than software requirements

I believe that when when business analysis is limited to (or centred around) the software development lifecycle, it ceases to be about defining the needs of the business and instead supports the main need of the solution provider: deliver software to schedule, which should be a means and not an end in itself. […]

Requirements vs Design

Scott Sehlhorst (@sehlhorst) has written an excellent article titled Requirements vs Design – Which is Which and Why? Some of my own thoughts are in this post, but read Scott’s article first to get the context.

Scott seems to gather the problems a business sees with its current model (e.g., […]

Business Rules versus Acceptance Criteria

Update: This post is from April 2012 and has been superseded by one from July 2016: Decision models, user stories and acceptance criteria

One of my readers contacted me recently to ask whether business rules and user story acceptance criteria could be considered the same thing.

Acceptance criteria are […]

Pegasystems’ DCO: an analyst’s perspective

I’m bumping this post because of some updates, as highlighted in green below. Note that this post relates to Pega 6.1 and was originally drafted in 2009.

Some of you Pega Business Architects were wondering how the modelling techniques I use relate to Pegasystems’ Direct Capture of Objectives approach, so […]

What is the business benefit?

As an analyst, it’s not enough to know what your customer wants. It is essential to unearth what the customer needs and how the customer’s business will benefit by fulfilling that need.

Customers are often the last to understand what their business truly needs, even when they have a clear idea […]

Activity Diagram tutorial Part 3: ignore variable details

Activity Diagram tutorial part 3 View more PowerPoint from Declan Chellar

Related posts:

System Use Case or Screen Flow? Using activity diagrams to model use cases What NOT to put in your Activity Diagram […]

Tracing Data Requirements

Just as functional requirements are traced from business need to implementation, data requirements should be traced to eliminate redundancy and ensure coverage.

The following slideshow lays out my procedure for tracing data requirements.

Tracing Data Requirements

View more presentations from Declan Chellar

Related posts:

The Importance of Data […]

Data modelling: start it early!

Whenever I mention data modelling on a project, everyone seems to assume I am talking about database design.

In my experience, on the vast majority of projects, both the Business and the service provider leave data modelling until they are at the screen design stage. At best, they might start modelling […]

What is a business rule?

Junior requirements analysts sometimes have difficulty with how to document business rules for information systems, or indeed, with recognising them in the first place. I hope this short article helps.

Some Definitions

“A rule under which an organization operates. A policy or decision that influences a process step.” (Data […]

It’s about the software

Many requirements analysis specialists have little or no development or testing experience and this can lead them to forget what the real deliverable is.

The purpose of requirements analysis is to provide a robust and unambiguous requirement so that architects and developers know what to build and testers know what to […]