CSC 308 Lecture Notes Week 9
Requirements for File and Edit Commands
Non-Functional Requirements

1. Requirements for file and edit commands.

   1. Following the requirements scenarios for the major commands of your system, cover any remaining details of file and edit commands.

   2. Put these details in one or two sections following the other functional requirements sections.

   3. For file commands, consider clearly what objects are saved to and opened from disk.

   4. For edit commands, consider clearly what objects are operated on by the cut, copy, and paste commands.
   
   
   

2. Requirements for error conditions

   1. Following the file and edit command section, include a section that covers error conditions.

   2. You need only summarize the error conditions you've covered already in earlier scenarios.

   3. For error conditions that have not yet been covered, show and describe the error display screens.

   4. You need only show one version of each generic error screen, listing the different error message texts.
   
   
   

3. Specification of error conditions.

   1. In the 308 specification methodology we do this with preconditions.

   2. From the user's perspective, each clause of a precondition corresponds to an error if the clause is not true.

   3. The error conditions described in the requirements correspond directly to violation of precondition clauses.

   4. We'll discuss the formalization of this further next week.
   
   
   

4. Other requirements

   1. Help -- not required for 308.

   2. Other GUI details -- not required for 308.

   3. Data entry details -- if necessary.
   
   
   

5. Non-functional requirements.

   1. So far in CSC 308 we've focused on functional requirements specification.

      1. We are answering the question "What does the system do?"

      2. This goes in Section 2 of the 308 requirements specification document.

   2. There are also non-functional requirements to be specified.

      1. For these we answering such questions as "How well", "How much?", and "How soon?" the system will perform, cost, and be delivered.

      2. These requirements go in Section 3 of the 308 requirements specification document.

   3. The non-functional requirements address aspects of the system other than the specific functions it performs.

   4. These aspects include system performance, costs, and such general system characteristics as reliability, security, and portability.

   5. The non-functional requirements also address aspects of the system development process and personnel.

   6. Formally, a non-functional requirement is one that is not part of the program model.

   7. There are three broad categories of non-functional requirements, elaborated on below: System-reated, Process-related, and Personnel- related.
   
   
   

6. Non-functional requirements by category.

   1. System-related non-functional requirements.

      1. performance

         1. time

         2. space

      2. operational environment

         1. hardware platform

         2. software platform

         3. external software interoperability

      3. standards conformance

      4. general characteristics

         1. reliability

         2. robustness

         3. accuracy of data

         4. correctness

         5. security

         6. privacy

         7. safety

         8. portability

         9. modifiability and extensibility

         10. simplicity versus power

   2. Process-related non-functional requirements.

      1. development time

      2. development cost

      3. software life cycle constraints

      4. system delivery

         1. extent of deliverables

         2. deliverable formats

      5. installation

         1. developer access to installed environment

         2. phase-in procedures to replace existing system

      6. standards conformance

      7. reporting

      8. marketing

         1. pricing

         2. target customer base

      9. contractual requirements and other legal issues

   3. Personnel-related non-functional requirements

      1. for developers:

         1. credentials

         2. applicable licensing, certification

      2. for users:

         1. skill levels

         2. special accessibility needs

         3. training
   
   
   

7. The spectrum of preciseness and quantifiability in non-functional requirements.

   1. Some constraints are easy to state quantifiably -- e.g., "The system will respond within 10 seconds to a user request for local data, and within 60 seconds for a remote data request."

   2. Some constraints and objectives are much harder to quantify -- e.g., the system will be "robust" and "user friendly"

   3. In 308, we are formalizing only the functional, not the non-functional requirements.
   
   
   

8. Cost/benefit/risk analysis.

   1. After a requirements specification is defined, it can be analyzed in terms of the costs, benefits, and risks involved in proceeding to develop the software.

   2. Computer system analysts are not necessarily qualified to produce cost/benefit analyses alone; they typically need to consult with finance experts as well as the potential software design/implementation team.

   3. The cost/benefit analysis can be included as a part of the requirements specification document or it can be a separate document.

   4. In 308, we do not have time to address cost/benefit analysis.
   
   
   
   

   ---

   index | lectures | handouts | examples | textbook | doc | grades

   ---