As the IIBA Business Analysis Body of Knowledge core team debates requirements categories, a lot of interesting questions are coming up about what is a requirement. Our definition, which is derived from the IEEE definition is "A requirement is a condition or capability needed by a stakeholder to solve a problem or achieve an objective." Does a screen prototype qualify?
Well, obviously, once it has been approved, a screen prototype is intended to solve a problem or achieve an objective. It has been requested by a stakeholder, someone (the executive sponsor) has agreed to pay for its development and ongoing maintenance, and an IT person has agreed that this visual display and associated functionality is technologically possible and fits with the enterprise architecture. Sounds to me like something that is needed by a stakeholder!
Is it a "condition" or "capability?" Well, even a simple inquiry screen provides information, facilitates decision making, and supports the enterprise mission so that sounds like a capability to me. A data entry or update screen provides users the ability to do work, this also sounds like a capability.
Some people say that a prototype is part of the design (a.k.a., design phase, deliverable package, specification). I don't disagree, but that doesn't exclude it from being referred to as a requirement. I vote yes, it is a requirement.
One unique feature of a prototype as a requirement: it typically does not survive the project. Once the screen is developed, the actual screen layout is used for documentation, user training, and maintenance documentation. Any enhancements to the software and screen are usually specified/documented using a grab of the actual screen layout. As such, a prototype is a requirement only until it's software component is built.
5 Comments
I make a very simple distinction between requirements and design; a requirement describes the problem space, design describes the solution space. To confuse one with the other is common and leads to much difficulty in scoping out exactly what the customer truly needs. The way I used to assess whether a statement is talking about the problem or the solution space is to test whether it is attempting to describe something that is an artefact, either existing now or would need creating. If the test is true then you are dealing with design and not requirements. The need for this distinction is that if your stakeholders are producing statements dealing with artefacts then they are doing design and not addressing their needs: do you really want unqualified people doing design, especially if they can’t articulate what their needs are for the artefact? To me a requirement is a statement about an outcome; how that outcome is achieved is the designer’s job, not the users.
Our PMO has a "Business Requirements" and a "Business Design" document. For a while my users and my analysts struggled with the difference, until I found it in – actually – the B2T training books: Requirements are the WHAT. Design is the HOW. (As Edmund says.) Now my users can tell the difference – and no longer demand prototypes early on – and we in the tech team can have effective review sessions by focusing on what each document should deliver. Often the final UI prototype changes the requirement as the business recognizes WHAT they should have addressed earlier. But the UI prototype itself is not a requirement.
Very excellent points made by Edmund and Frederica. I would like to add a couple of points to clarify how B2T Training uses the word requirements. I think we are all saying the same things but we are using slightly different terminology. B2T Training courses differentiate "Business" requirements from "Functional requirements." Business requirements define the "what" as Frederica mentions and define the problem space as Edmund describes. Business requirements are implementation independent and do express the customer needs. "Functional" requirements are separate from business requirements and define "how" the software is expected to behave. We continue to use the term requirements because functional requirements (like prototypes) refine the capabilities expressed in business requirements during design and additionally defining these requirements relies on significant interaction with the customer to define excellent functional (design) requirements in the solution space. Prototyping is ideally accomplished with assistance from the customer, BA and IT team member. We do not believe that requirements are just tossed over the wall to the IT team for design.
Most of the explanation about requirement i ever read, said that screen prototype is not “requirement”. When i gathered requirement and put all business problem and stakeholder request into document needed, screen prototype is one of the important point to put in. It will help Developers understand business requirement easily because screen prototype will also describes business needed and stakeholder request more than just text description and system flow. So, I also vote that “screen prototype” is a “Requirement”.
While seeing one such debate earlier; that are models requirements and now this one. I agree to what barbara has said that both are “REQUIREMENTS”.
First whenever any requirements is taken assume for a while that there’s no tool involved, it’s simply verbal; in this case too the person who’s taking it all will either be doing all by itself or will be telling other to do as he heard. And the same goes for having a tool involved, because a model diagram depicts the true picture of what’s been “REQUIRED”; hence marking it as a requirment. When it comes to make an ERD; that shows how requirements are or will be catered both in logical and physical forms. Finally MODELS are REQUIREMENTS
Coming on to are prototypes; surely they are too requirements. Here I would try to categorize Data Model and the GUI. An ERD as cited above a Requirement. GUI too is a requirement; as mentioned by barbara; that they are also finalized when approved. Further, prototypes too are normalized before being finalized, ensuring that whatever information they will carry will be adequate to be displayed on a particular interface (GUI)/form. Also how other controls are handled; and this is all by considering the data model which pertains to the overall data strucutre of the project.
So, I too go with those who say that PROTOTYPES are “REQUIREMENTS”