GS Requirements Standard

Design icon.png This page contains the design document for an enhancement or feature. The design should be considered a work in progress and may not represent the final design. As this is a collaborative design, contributions and participation from other developers and users is encouraged. Use the discussion page for providing comments and suggestions.



Notes on requirements

  • The aim of user requirements capture is to produce an overall System Requirements Model, one use at a time. This formalizes the client needs and establishes a list of mandates. All design implementation and testing models are generated from these requirements.
  • The requirements model must be readable by all parties, aka, written in terms that the client can understand. However, the requirements must contain sufficient detail to facilitate:
    • The developer's use of it to analyze and design the system.
    • Testers use to generate tests.
    • Documenters use to write user and system documentation.
  • Requirements must be gathered and refined iteratively by discussion among developers and clients.
  • The goal is to produce a list of requirements where each requirement precisely identifies a single function. If a requirement seems too general or broad scoped, then break it down into smaller requirements.
  • During the process of identifying Requirements, new Actors and new Use Cases will become appearent.





Sample Requirements

GSNetLib
  • Provide a means to connect to other GS based applications.
  • Provide a means to listen for connections from other GS based applications.
  • Provide a means to accept connections from other GS based applications.
  • Provide a means to transport GS-messages to other GS based applications.
  • Provide a means to recieve GS-messages from other GS based applications.