Identify the requirements: A Product Requirements Document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.

In today’s Lean and Agile world, the PRD may be trimmed down (or simply represented by a prototype) so we’ll focus on just the core...

In today’s Lean and Agile world, the PRD may be trimmed down (or simply represented by a prototype) so we’ll focus on just the core elements.
The PRD is the heart of your product and serves as a living document for any designer, developer, or stakeholder to understand the status and purpose of the product.

A Product Requirements Document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
http://www.svpg.com/assets/Files/goodprd.pdf

As illustrated above, failure to document requirements can lead to wildly different assumptions. Because there’s been debate around the danger of excessive design thinking as well as its vital role in product leadership, the PRD helps balance the design team’s focus on usability and aesthetics against engineering’s functional concerns.
For a detailed PRD, you can reference this expansive PRD template. For a more lightweight option, check out how to write a simple PRD.
The product curation company Product Hunt shows that a PRD doesn’t need to be 100 pages long — just define the problems the product will solve with a general description of features (and plenty of mockups from previous stages). The technical details should be saved for the FSD.




Properly written requirements define the "WHAT" of a product. WHAT does the product do for the user, specifically? For example,

 if the product is a ventilator, 

the list of WHAT it does...

 (may include a statement such as)

"If power is lost during operation, the wearable device shall resume operation according to its last programmed settings within 250 ms of power up."

Note that a properly written requirement is silent about HOW this particular part of the overall WHAT is to be achieved. The implementation could be purely electronics or a combination of electronics and firmware; the firmware, if present, might contain an RTOS or it might not. From the point of view of the requirement writer..

Each requirement statement must also be two other things:
  1. unambiguous 
  2. testable
An unambiguous statement requires no further explanation. It is as clear and as concise as possible. If the requirement includes a mathematical model of expected system behavior, it is helpful to include the equations.

Testability is key.

 If a requirement is written properly, a set of tests can be easily constructed to verify that requirement is met. Decoupling the tests from the particulars of the implementation, in this manner, is of critical importance. Many organizations perform extensive testing of the wrong stuff. Any coupling between the test and the implementation is problematic.

A proper set of requirements is a written list of statements each of which contains the key phrase "

 the [product] shall ..." and is silent about how it is implemented, unambiguous, and testable. 

This may seem like a subject unrelated to architecture, but too often it is poor requirements that constrain architecture. Thus good architecture depends in part on good requirements. 


The Anatomy of the Product Requirements Document (PRD)

Once you get to the “Build It” phase, the previous research and prototyping should give your team a high-level understanding of your product. All companies are different, so some stages of product development can happen simultaneously (instead of sequential).
Regardless, you should be able to ask any 5 team members about the overall
  1. purpose, 
  2. features, 
  3. release criteria, 
  4. and timeline for the product 

and they should give you roughly the same answer. 

Step 2: Distinguish architecture from design
Over the years, I have found that many engineers (as well as their managers) struggle to separate the various elements or layers of firmware engineering. For example, Netrino is barraged with requests for "design reviews" that turn out to be "code reviews" because the customer is confused about the meaning of "design." This even happens in organizations that follow a defined software development lifecycle. We need to clear this up.

The architecture of a system is the outermost layer of HOW. Architecture describes persistent features; the architecture is hard to change and must be got right through careful thinking about intended and permissible uses of the product. By analogy, an architect describes a new office building only very broadly. A scale model and drawings show the outer dimensions, foundation, and number of floors. The number of rooms on each floor and their specific uses are not part of the architecture.4

Architecture is best documented via a collection of block diagrams, with directional arrows connecting subsystems. The system architecture diagram identifies data flows and shows partitioning at the hardware vs. firmware level. Drilling down, the firmware architecture diagram identifies subsystem-level blocks such as device drivers, RTOS, middleware, and major application components. These architectural diagrams should not have to change even as roadmap features are added to the product—at least for the next few years. Architectural diagrams should also pass the "six-pack test," which says that even after drinking a six pack of beer, every member of the team should still be able to understand the architecture; it is devoid of confusing details and has as few named components as possible.5

The design of a system is the middle layer of HOW. The architecture does not include function or variable names. A firmware design document identifies these fine-grained details, such as the names and responsibilities of tasks within the specific subsystems or device drivers, the brand of RTOS (if one is used), and the details of the interfaces between subsystems. The design documents class, task, function/method, parameter, and variable names that must be agreed upon by all implementers. This is similar to how a design firm hired by the renter of a floor on the office building describes the interior and exterior of the new building in finer detail than the architect. Designers locate and name rooms and give them specific purposes (e.g., cube farm, corner office, or conference room).

An implementation is the lowest layer of HOW. There need be no document, other than the source code or schematics, to describe the implementation details. If the interfaces are defined sufficiently at the design level above, individual engineers are able to begin implementation of the various component parts in parallel. This is similar to the way that a carpenter, plumber, and electrician work in parallel in nearby space, applying their own judgment about the finer details of component placement, after the design has been approved by the lessee.

Of course, there is architecture and there is good architecture. Good architecture makes the most difficult parts of the project easy. These difficult parts vary in importance somewhat from industry to industry, but always center on three big challenges that must be traded off against each other: meeting real-time deadlines, testing, and diversity management. Addressing those issues comprise the final three steps.

Step 3: Manage time
Some of your product's requirements will mention explicit amounts of time. For example, consider the earlier ventilator requirement about doing something "within 250 ms of power up." That is a timeliness requirement. "Within 250 ms of power up" is just one deadline for the ventilator implementation team to meet. (And something to be tested under a variety of scenarios.) The architecture should make it easy to meet this deadline, as well as to be certain it will always be met.

Most products feature a mix of non-real-time, soft-real-time, and hard-real-time requirements. Soft deadlines are usually the most challenging to define in an unambiguous manner, test, and implement. For example, in set-top box design it may be acceptable to drop a frame of video once in a while, but never more than two in a row, and never any audio, which arrives in the same digital input stream. The simplest way to handle soft deadlines is to treat them as hard deadlines that must always be met.

With deadlines identified, the first step in architecture is to push as many of the timeliness requirements as possible out of the software and onto the hardware. Figure 1 shows the preferred placement of real-time functionality. As indicated, an FPGA or a dedicated CPU is the ideal place to put real-time functionality (irrespective of the length of the deadline). Only when that is not possible, should an interrupt service routine (ISR) be used instead. And only when an ISR won't work should a high-priority task be used.


View the full-size image

Keeping the real-time functionality separate from the bulk of the software is valuable for two important reasons. First, because it simplifies the design and implementation of the non-real-time software. With timeliness requirements architected out of the bulk of the software, code written by novice implementers can be used without affecting user safety.6

The second advantage of keeping the real-time functionality together is it simplifies the analysis involved in proving all deadlines are always met. If all of the real-time software is segregated into ISRs and high-priority tasks, the amount of work required to perform rate monotonic analysis (RMA) is significantly reduced. Additionally, once the RMA analysis is completed, it need not be revised every time the non-real-time code is tweaked or added to.

source
http://www.embedded.com/design/prototyping-and-development/4008800/2/Firmware-architecture-in-five-easy-steps
Name

background,4,ee,12,new,4,
ltr
item
RajEngineer.com - Analog, Digital, Mixed-Signal, PCB, Electrical Design Engineering: Identify the requirements: A Product Requirements Document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
Identify the requirements: A Product Requirements Document (PRD) is a document containing all the requirements to a certain product. It is written to allow people to understand what a product should do.
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLWfySff013ZY4vmbUtadM1aSYQaZ0YlZjTe1_xjjAE2jzbAd1BJxOMwh0bMAgJawSs-sqjode83w66jU04GGf4RngjKtEWkK6isBFO2o5NlaI7zG_Bv7pDY5aL22aiNB3XV5hskUFvdA/s640/product+requirements.png
https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiLWfySff013ZY4vmbUtadM1aSYQaZ0YlZjTe1_xjjAE2jzbAd1BJxOMwh0bMAgJawSs-sqjode83w66jU04GGf4RngjKtEWkK6isBFO2o5NlaI7zG_Bv7pDY5aL22aiNB3XV5hskUFvdA/s72-c/product+requirements.png
RajEngineer.com - Analog, Digital, Mixed-Signal, PCB, Electrical Design Engineering
https://www.rajengineer.com/2016/10/identify-requirements-and-testability.html
https://www.rajengineer.com/
https://www.rajengineer.com/
https://www.rajengineer.com/2016/10/identify-requirements-and-testability.html
true
6766059806102944349
UTF-8
Loaded All Posts Not found any posts VIEW ALL Readmore Reply Cancel reply Delete By Home PAGES POSTS View All RECOMMENDED FOR YOU LABEL ARCHIVE SEARCH ALL POSTS Not found any post match with your request Back Home Sunday Monday Tuesday Wednesday Thursday Friday Saturday Sun Mon Tue Wed Thu Fri Sat January February March April May June July August September October November December Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec just now 1 minute ago $$1$$ minutes ago 1 hour ago $$1$$ hours ago Yesterday $$1$$ days ago $$1$$ weeks ago more than 5 weeks ago Followers Follow THIS PREMIUM CONTENT IS LOCKED STEP 1: Share. STEP 2: Click the link you shared to unlock Copy All Code Select All Code All codes were copied to your clipboard Can not copy the codes / texts, please press [CTRL]+[C] (or CMD+C with Mac) to copy