Skip to content
BoKSA

Technical Requirements Analysis

Technical Requirements Analysis

Requirements decide what gets built and how you will know it succeeded. Business, user, and system requirements are different things, and so are functional and non-functional requirements — mixing them up is a common cause of rework. Writing requirements as clear, testable statements ("The system shall…"), backed by use cases or operational scenarios and acceptance criteria, gives you and your stakeholders a shared, checkable definition of "done" for a device that also has timing, power, and safety limits.

Starting Points

  • SWEBOK Guide — "Software Requirements" chapter (IEEE Computer Society).
  • Wiegers, K. E., & Hokanson, C. (2023). Software Requirements Essentials. Addison-Wesley.
  • Requirements engineering fundamentals

Key Points

  • You identify stakeholders and derive functional and non-functional requirements for an embedded or robotic system.
  • You translate informal stakeholder wishes into clear, structured requirement statements.
  • You describe use cases or operational scenarios (actors, main flow) with matching acceptance criteria.
  • You review a set of requirements for ambiguity, missing information, and testability, and propose concrete improvements.
  • You explain how your requirements link to acceptance tests, including hardware-in-the-loop or lab checks where software tests are not enough.