| TankFish wrote
Ok, so I see this diagram as maybe being the middle tier then. Based on the diagram we would have something like this.
Business Requiremenst (1st)
We need a web based system that our customers can logon to and view/download the data transmitted by their loggers in the field. Each customer must only be able to see their site and its data.
System Requirement (2nd)
See diagram.
Functional Requirements (3rd)
- The logger needs to transmit to the server by secure GPRS
- Logger ID
- SIM number
- PIN
- Date transmitted will be as follows
- Date: YYYY-MM-DD
- Time: HH:mm:ss
- LoggerID
- 6 character unique numeral
- Channel 1 Value(CH1)
- 10 Character numeral with decimal point
- Channel 2 Value(CH2)
- 10 Character numeral with decimal point
- Channel 3 Value(CH3)
- 10 Character numeral with decimal point
- Data string will be transmitted in the following format
- DDDD-MM-YY|HH:mm:ss|LoggerID|CH1|CH2|CH3
- etc
- etc
- Data file must be available in PDF
- Format as follows
- Header
- Logger ID
- Date Period Report Run for
- User who ran report
- Body
- Line Graph plotting data
- Formar: JPEG
- All channels on one graph
- X & Y Axis must auto scale to range of values
- X = Date Range
- Y = Data Points
- Data in Table format
- Table Header Rows (Bold)
- Date
- Time
- CH1
- CH2
- CH3
- Table Data Rows (1 for each data point)
- Date
- Time
- CH1
- CH2
- CH3
- Footer
- Company Information
- Company Name
- Contact Number
- Website Address
- Must be link to company website
- etc
- etc
Is that correct? Will the BRD almost always be shorter than the FRD?
|
I have some comments:
a) I encourage stakeholders to provide separate business requirements to distinguish one from another. It helps me organize things better, personally. For example:
- Allow customers to view the data transmitted by their loggers in the field;
- A customer must only be able to see information that pertains to them;
- Provide our customers with transmission information upon request.
b) It appears that perhaps a tech influenced the business requirements documentation more than the stakeholders. There are solutions mixed in with requirements. For instance, it's not necessary up-front to require that the system be Web-based --even if that's the popular route these days. Who knows, perhaps a developer would devise a more advantageous stand-alone solution (not likely, I know, but just consider the point that I'm trying to make)? I also removed the requirement for "downloading" the data; perhaps another transmission solution would be proposed by a member of another team other than the stakeholder's. Perhaps even an automated process would be devised? The bottom line is that customers need to view and receive transmission information pertinent to them. That simple, and that could even have been the complete business requirement.
c) Functional requirements 1 and 6 include system solutions. Bullets 3 through 6 of functional requirement 2 do not seem to pertain to dates. Point 1 is purely a system solution; security is a measure that must always be expected and the technical staff must determine the solution. In point 6, who decided that the file "must" be available in .pdf format (seems more like a tech solution)?
Regards,
vinny