Comments on: Is a Screen Prototype a “Requirement?” http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/ Connecting Business Requirements to Technology Mon, 30 Jan 2012 21:31:56 +0000 hourly 1 By: Syed Mumshad Ali http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/comment-page-1/#comment-17 Syed Mumshad Ali Tue, 26 Dec 2006 07:26:18 +0000 http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/#comment-17 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" 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”

]]> By: Frida http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/comment-page-1/#comment-16 Frida Thu, 30 Nov 2006 10:33:24 +0000 http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/#comment-16 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". 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”.

]]> By: Angie Perris http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/comment-page-1/#comment-15 Angie Perris Tue, 20 Jun 2006 21:01:43 +0000 http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/#comment-15 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. 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.

]]> By: Frederica http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/comment-page-1/#comment-14 Frederica Mon, 22 May 2006 20:51:14 +0000 http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/#comment-14 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. 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.

]]> By: Edmund http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/comment-page-1/#comment-13 Edmund Mon, 15 May 2006 19:29:21 +0000 http://www.b2ttraining.com/2006/05/15/is-a-screen-prototype-a-requirement/#comment-13 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. 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.

]]>