The A-Spec, or System Specification, is the cornerstone of your capstone project. It represents the culmination of your efforts, translating all the previous analysis and design work into a clear set of specifications that a contractor could use to develop the system.
The A-Spec is the primary output from the Concept Definition life cycle phase (Kossiakoff SE P&P Chapter 7). The textbook calls it a "Functional Specification".
Here are some key points and common mistakes to watch for.
The A-Spec is designed to be part of a notional request for proposal (RFP) and subsequent development contract. It should be detailed enough to guide the development of your system while allowing flexibility for design engineers.
The Requirements Analysis Report captured your Stakeholder and System-Level requirements at the black-box level, without peering into or defining the internal workings of your system.
Now that we've delved into the structure of the system, penetrating its boundaries to define its internal workings and structure (captured in the Functional Analysis and Concept Design Reports), we must convert what we've discovered about these internal elements into sub-system-level requirements in the A Spec at the white-box levels.
Thus, the A-Spec defines both black box and white box for the system, focusing on high-risk, critical and immature elements.
If the amount of work required to create even more requirements for each subsystem sounds daunting, do not be dissuaded. Keep in mind we're here to demonstrate that we have the subject of SE mastered, not to create a complete, ready-to-place-on-contract conceptual design. Thus, we should mainly focus on high-risk, critical and immature elements in the A Spec and keep the 'rest' high level and holistic.
As you progress from the RAR to the A-Spec, your requirements should grow and evolve. This growth is essential, particularly in the number of quantified requirements. If your A-Spec looks very similar to your RAR, with little refinement or addition of detailed performance metrics, it may indicate insufficient development of your system concept.
A common issue is the presence of too many non-quantified requirements. Aim to have more than 75% of your requirements be measurable and testable. This makes the requirements verifiable and ensures that the system can be objectively assessed during development.
Provide notional design engineers with sufficient trade space, meaning that while your specifications should be clear, they should not be so rigid that they stifle innovation or practical design decisions. The A-Spec should guide but not overly constrain the engineers who will develop the system.
Low Number of Quantified Requirements: Ensure most requirements are measurable, with clear thresholds and objectives.
Too Abstract Requirements: Requirements should be detailed enough to prevent any ambiguity that could lead to misinterpretation or exploitation by developers. See the Characteristics of Good Requirements on the RAR page.
Over-Specification: Avoid specifying particular solutions (e.g., a specific brand or model of a component) that may limit the flexibility of the design process.
Unchanged Requirements: If your A-Spec closely mirrors your RAR without significant changes or additions, it suggests a lack of progression in your project.
Over-Stepping Roles: Remember, you are a systems engineer, not the design engineer. Your role is to set the requirements and constraints, not to dictate specific design choices.
Before finalizing your A-Spec, ask yourself if you would feel comfortable placing a contractor on contract to develop your system based on these specifications. If the answer is no, additional work may be necessary to refine and improve the A-Spec.
Feel free to use an LLM like ChatGPT, Claude, Gemini or Grok to help create and refine your requirements.
Here's what I did for my ATM concept for my teaching material:
I looked at my functional flow diagrams with swimlanes and, using voice-to-text in Google Docs (far superior to Window's VTT), I explained what was going on in the diagram: The inputs, the outputs, and the functions that are being performed by each of the elements.
I then pasted my text as a prompt in ChatGPT to quickly generate requirements. In the below example I focused on my cash management subsystem.
Prompt: "I have decomposed my ATM requirements down to the component level. I've identified the primary functions that the cash management subsystem must perform. They are as follows:
Cash Management Computer: Upon receiving the desired amount, select the appropriate vault (to a degree of accuracy). Provide role-based access throughout the cash dispense activity (always). Protect against malware and intrusions throughout the cash dispense activity (to a degree of security). After a bill is grabbed, check if the bill type selected matches the bill type requested (to a degree of accuracy). After each bill is grabbed, keep a count of the bills distributed (to a degree of reliability).
Cash Vault: Store 1 to 500 bills (always). Prevent physical tampering (including... List potential types of physical tampering at the internal vault level).
Bill Separator: After a vault is selected, grab and send a bill from the bill storage in the cash vault (at a certain speed/rate and degree of accuracy).
Bill Sensor Assembly: When the bill separator grabs a bill, verify that a bill was indeed grabbed (to a degree of reliability and at a certain speed). When the bill separator grabs a bill, verify that the bill grabbed matches the bill requested by the user (to a degree of reliability and at the same speed). After a bill is stacked, inform the cash management computer that a bill was stacked.
Bill Transport Belt Assembly: After a bill is grabbed by the bill separator, transport the bill for type verification (to a certain degree of reliability and at a certain speed). This speed should match the overall throughput for the cash management subsystem. If a faulty bill is grabbed, store the faulty bill in a separate container (always).
Bill Stacker Assembly: After a bill is verified as the correct type, stack the bill in the bill stacker assembly (at a certain speed). After all bills to be stacked are stacked, present the stack to the user for retrieval within a certain time limit.
Instruction: Convert all of these functions into requirement 'shall' statements, following best practices for requirement 'shall' statements, including the inclusion of threshold and objective performance values. Quantify each where possible. I've provided hints for quantification, such as timeframes, reliability, and so on. Present your output in a table with separate columns for number, requirement title, and requirement 'shall' statement. Each requirement statement should specify the type of component or assembly that performs the function, for example, 'The bill separator shall...'"
Chat GPT generated the following requirements as an output:
1. Vault Selection AccuracyThe Cash Management Computer shall select the appropriate vault based on the desired amount with an accuracy of ≥ 99.9% (T), 99.99% (O).
2. Role-Based Access EnforcementThe Cash Management Computer shall enforce role-based access control throughout the cash dispense operation with no failures permitted (T/O = always).
3. Malware and Intrusion ProtectionThe Cash Management Computer shall protect against malware and intrusion during the cash dispense operation to a minimum of Common Criteria EAL4+ (T), EAL5+ (O).
4. Bill Type Verification AccuracyThe Cash Management Computer shall verify that the type of bill grabbed matches the requested denomination with an accuracy of ≥ 99.5% (T), 99.9% (O).
5. Bill Count ReliabilityThe Cash Management Computer shall count the number of bills dispensed with a reliability of ≥ 99.9% (T), 99.99% (O).
6. Bill Storage CapacityThe Cash Vault shall store between 1 and 500 bills at all times (T/O = always).
7. Physical Tamper ResistanceThe Cash Vault shall prevent physical tampering including prying, cutting, drilling, thermal attacks, and unauthorized access to UL 291 Level 1 (T), Level 3 (O).
8. Bill Separation Speed and AccuracyThe Bill Separator shall grab and send a bill from the selected vault in ≤ 0.75 sec/bill (T), ≤ 0.5 sec/bill (O) with an accuracy of ≥ 99.5% (T), 99.9% (O).
9. Bill Grab Detection ReliabilityThe Bill Sensor Assembly shall detect whether a bill was grabbed with reliability of ≥ 99.9% (T), 99.99% (O), within ≤ 0.75 sec (T/O).
10. Bill Type Classification ReliabilityThe Bill Sensor Assembly shall verify the type of the grabbed bill with reliability of ≥ 99.9% (T), 99.99% (O), within ≤ 0.75 sec (T/O).
11. Bill Stack Notification LatencyThe Bill Sensor Assembly shall notify the Cash Management Computer after each bill is stacked within ≤ diluted ms (T/O).
12. Bill Transport Reliability and SpeedThe Bill Transport Belt Assembly shall transport a bill for verification with reliability of ≥ 99.95% (T), 99.99% (O), at ≥ 1.2 bills/sec (T), 1.5 bills/sec (O).
13. Faulty Bill Handling ReliabilityThe Bill Transport Belt Assembly shall divert faulty bills to a separate container with 100% reliability (T/O = always).
14. Bill Stacking RateThe Bill Stacker Assembly shall stack verified bills at ≥ 1.2 bills/sec (T), 1.5 bills/sec (O).
15. Cash Stack Presentation TimeThe Bill Stacker Assembly shall present the completed bill stack to the user within ≤ 2.5 sec (T), ≤ 2.0 sec (O) after final stacking.
I can then import these into my modeling tool and link them to the elements that satisfy them in a satisfy trace matrix (Catia Magic).
The whole thing for the Cash Management SS took about 10 min.
Keep in mind, I've only captured functional requirements for the Cash Management SS. I would still need to create the non-functional or 'ilities' requirements if I wanted to be more thorough. An LLM can help generate these as well.
System Specification (A-Spec)
Any additional functional requirements are added to the original list.
Requirements Table is updated—no less than 75% of requirements should be quantitative, and 100% should quantitative or binary. There are very few exceptions to this. All need some verification method. Sometimes, you will need to perform additional research or analysis to make a requirement quantitative. That’s OK—I expect this. I recommend using the same table as you did in the RAR with any updated columns. Overachievers: include additional columns for your subsystems and allocate relevant requirements to those subsystems.
At this point the A-Spec requirements may be organized along these lines:
General/operational
Overall functional
Overall performance
External interfaces
Subsystem-specific functional/performance
Internal interfaces
–ilities
Safety
KPPs should be broken out in a separate table (these may or may not have changed from your Requirements Report). KPPs should be quantitative at this point; although one or two binary KPPs are allowed. Absolutely NO qualitative KPPs are allowed.
The system, as a whole, needs to have an availability spec and an overall reliability spec (make sure you know the difference). Then each subsystem needs a reliability spec (no availability spec is needed at the subsystem level).
Other support requirements are added (-ilities; MTBF; logistics; maintenance; etc.)
Safety requirements are added (if applicable)
Human-System Interface (HSI) requirements are added (remember who your users are).
Trace the new requirements list to your functional architecture.
Any special instructions to designers, if applicable.
Total number of requirements should have grown about 20-30% from the Requirements Analysis Report. (include the table).
You can combine some of the above in a single table (like specifications, verification and allocation to a subsystem).
A-Spec Checklist Credit: Steve Biemer