Michael Blechar

Arguably, the vast majority of development organizations are primarily focused on “getting the requirements from the users” and as rapidly as possible coding a solution using some engineering process. The person getting the definition of the “requirements” might be the lead IT analyst or developer on a project team, or possibly the requirements are coming from a “business analyst” residing in IT – or more frequently now residing in the business unit. But the concept of “requirements” and development processes are changing in the delivery of next-generation applications. Here, I will discuss the former, while in my companion blog on “Agile Methodologies” I will explore the latter.

Requirements come in many categories, types and formats — and, in fact, may not even be "required." In my recently published research note, “The Perspective of ‘Requirements’ Varies by Role and Context*”, I examine what most organizations consider to be "requirements," how they are captured and how to ensure the delivered solutions meet business expectations. People use the term "requirement" to mean different things. Requirements tend to fall into one of two categories — functional (which addresses needs and outcomes, specifications and rules) and nonfunctional (which deals with issues, such as performance, security and localization issues).

For most organizations, the requirements are documented in some form of text or spreadsheet, such as Microsoft Word or Excel. However, requirements are not always best stated as text in a document or spreadsheet. There are also common elements associated with regulations, business goals and other cross-application information that should be captured as a reference across projects — possibly in other formats, such as modeling languages and use cases, architectural and design patterns, and frameworks, rule engines, decision tables, and data or metadata. It is key not only that information is captured, but also that it is easily found and navigated; otherwise, this information will quickly become lost.

Without going into detail here, simply stated, all organizations ought to have a requirements management strategy in place that includes a range of approaches from ad hoc through comprehensive alternatives based on business value and risk. This should include guidelines on how much rigor to apply to managing different types of requirements and how to ensure that mandated enterprise architecture and governance, risk and compliancy (GRC) requirements are being satisfied. The technologies that support this strategy include modeling, metadata management, requirements tracking and automated testing tools.

For more information on requirements, see the following research notes*.

-“The First Key to Project Success Is Collaborative Requirements Definition and Management”
-“Beware the Emerging Role of the Project Analyst/Manager”
-“Creative Briefs Trump Feature Request Lists”
-“Gartner’s Business Pattern Framework Helps Identify Process Agility Requirements”

*Available to Gartner clients or for a fee.

Submit a Comment »

Category: Uncategorized     Tags:

Share

Tweet