Software Requirements Specification Checklist
General (SRS requirements) Checklist
- Is a functional overview of the system provided?
- Are overviews of the system's modes-of-operations provided?
- Have the software and hardware environments been specified?
- If assumptions that affect implementation have been made, are they stated?
- Have the functionality of hardware or software interacting with the system been properly specified?
- Has every acronym, constant, variable, and timeout been defined in the Data Dictionary?
- Are all the requirements, interfaces, constraints, definitions, etc. listed in the appropriate sections?
- Are all inputs to the system specified, including their source, accuracy, range of values, and parameters?
- Are all inputs to the system specified, including their source, accuracy, range of values, parameters and frequency?
- Are all outputs from the system specified, including their destination, accuracy, range of values, parameters and format?
- Are all screen formats specified?
- Are all report formats specified?
- Are all interface requirements between hardware, software, personnel, and procedures included?
- Are all communication interfaces specified, including handshaking, error-checking, and communication protocols?
Behavioral Requirements Checklist
- Have all requirements described in the problem statement and in subsequent communications with the customer been specified?
- Are all inputs to a function sufficient to perform the required function?
- Are undesired events/inputs considered and their required responses specified?
- Have the types, initial values, units been defined for every object attribute?
- Have the parameter and return types of all object operations been defined?
- Have all OMT internal events (actions/messages appearing in dynamic models that are not invocations of object operations) been defined? There should be a short description for each internal
event, specifying the event's source, destination (or broadcast), parameters, and brief definition.
- Have all internal SDL signals been defined? There should be a short description for each internal signal, specifying the events source destination, parameters, and brief definition.
- Have the accuracy, precision, range, type, rate, units, frequence of inputs and outputs been specified for each function?
Non - Behavioral Requirements Checklist
- Is the expected response time, from the user's point of view, specified for all operations?
- Is the level of security specified?
- Is the reliability specified, including the consequences of software failure, the vital information that needs to be protected from failure, and the strategy for error detection and
- Is the maximum memory specified?
- Is the maximum storage specified?
- Are planned changes specified (i.e., maintainability)?
- Are acceptable trade-offs between competing non-behavioral properties specified?
SDL Notation Checklist
- Have all external signals been declared in the system spec?
- Have all internal signals been declared in the block specs?
- Have all data variables and timers been declared?
- Have all data variables been initialized?
- Are all timers reset when they are no longer needed?
- Does every process have a start state?
- Process states should not be followed by anything other than an input symbol.
- Input symbols should only appear as the first symbol in a transition between states.
- At every state, has the receipt of any possible input been considered?
Object Model Notation Checklist
- Have the multiplicities of all associations been considered?
- Are each object's attributes really data values? (Attributes that are objects themselves should be modeled using aggregation.)
- Have generalizations of objects been considered?
- Should aggregations of a generalized class really be aggregations of the specialized classes?
- Are each object's operations really operations on the object's attributes? (Operations invoked by the object's dynamic model are often operations on another object's data.)
Dynamic Model Notation Checklist
- Are there any state-transitions that can never occur (because the event never occurs)?
- Are all remote operations (of other objects) invoked as either an action or a message?
- Are all messages sent during a state transition (and not from a state)?
- If a remote method is invoked, does the remote object return the results of the call?
- Are all state transitions deterministic?
- Are all attributes used in the dynamic model declared in the object model?
- Are all operations called in the dynamic model declared in the object model?
- Do all superstates have an initial state?
- Have special states (e.g., abnormal termination) been considered?
Functional Model Notation Checklist
- Are the inputs and outputs to the functional model data flows?
- Are control flows unintentionally used to pass data?
- Arrows into data stores should only be used to indicate that data in the store is changed.
- Do any of the functional models display dynamic behavior (e.g., "display error message") which should be moved to the dynamic model of the appropriate object?
- Is there a functional model for every activity in the dynamic models?
- Is there a functional model for every operation defined in the object model?
- Are attributes used in the functional model declared in the object model?
- Does every process in the functional models have a single output?
- Does each requirement avoid conflicts with other requirements?
- Do the requirements avoid specifying design?
- Are the requirements at a fairly consistent level of detail? should any requirement be specified in more detail? Should any requirement be specified in less detail?
- Are the requirements clear enough to be turned over to an independent group for implementation and still be understood?
- Is each requirement testable? Will it be possible for independent testing to determine whether each requirement has been satisfied?
Category Checklists Category Exam 70-155 Hot Topic Category Exam 70-156 Hot Topic Category Requirements
( Topic last updated: 2000.03.09 02:41:14 PM )