Team 28

Describes the purpose of the document, and the intended audience.

Describes the scope of this requirements definition effort. Introduces the requirements elicitation team, including users, customers, system engineers, and developers. This section also details any constraints that were placed upon the requirements elicitation process, such as schedules, costs, or the software engineering environment used to develop requirements.

Identify here the business needs for your project.(if applicable) It’s important to realize that some projects are driven by opportunities, not problems. For example, stakeholders might save xx% in operating costs if they change to a new software.

List here the most important related research work (Maximum 3 papers). Be sure that each paper you list include the following points

1. The main problem statement of the work.

2. How the researchers contributed to solve the problem

3. The dataset used by the researchers

4. What main results the researchers reach.

5. Criticize the paper

6. Figure/s of the work (if available)

Describe similar available business applications the the market with figures. (Optional) (Maximum 2)

This section describes the essential problem(s) currently confronted by the user community.

Provides a brief overview of the product defined as a result of the requirements elicitation process. System Overview Diagram.

Define The scope of your project. The scope should briefly:

• Define the boundaries of the project.

• Define the expected outcomes of the project.

State the context of the system, the boundaries of the system and if the system interacts with any external component. Show all this in a Context Diagram also.

This section describes the set of objectives and requirements for the system from the user’s perspective. It may include a “wish list” of desirable characteristics, along with more feasible solutions that are in line with the business objectives.

Describes the features of the user community, including their expected expertise with software systems and the application domain. (100 word Limit)

Describes the general functionality of the product using Use Cases diagrams. You also need to list project requirements. A good requirement states something that is necessary, verifiable, and attainable. Even if it is verifiable and attainable if it is not necessary, it is not a good requirement [1]. For example:

1. The user shall be able to search either all of the initial set of databases or select a subset from it.

2. The admin shall update security rules.

3. The user shall be able to create a new event.

Show the details of the main functions (minimum 3 – maximum 6) shown in section 4.1. Describe each function in the following structure.

Specifies any constraints for the design team using this document. (100 word Limit)

Specifies any other particular non-functional attributes required by the system. Such as: Security, Reliability, Maintainability, Portability, Extensibility. (200 word Limit)

Dataset/Database Description (200 word Limit)

Initial Class Diagram

This section should describe a set of scenarios that illustrate, from the user’s perspective, what will be experienced when utilizing the system under various situations. In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows: In the broad sense, a scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use case, which consists merely of a short description with a number attached. More detailed forms are called scripts. These are usually represented as tables or diagrams and involved identifying an action and the agent (doer) of the action. For this reason, a script can also be called an action table. Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because the describe the system’s behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.

This section provides the project plan from previous phase to next phase (proposal to SDD), including the major tasks to be accomplished, their inter-dependencies, and their tentative start/stop dates. The plan also includes information on hardware, software, and resource requirements. The project plan should be accompanied by one or more PERT or GANTT charts such as the chart shown in Figure 1. The plan should include the projects task and who is responsible for this task. Table 3 shows a simple example.

Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:

Provides definitions of unfamiliar definitions, terms, and acronyms.

Provides definitions of unfamiliar definitions, terms, and acronyms.

[1] Ivy Hooks. “Writing good requirements”. In: INCOSE International Symposium. Vol. 4. 1. Wiley Online Library. 1994, pp. 1247–1253.

Note that you should use 10 Reference Minimum (80% Academic)