Synopsis

The report documents the development of a requirements engineering software tool.

Using the Requirements Engineering Software Tool the persons can

• Manage initial requirements.

• Create a standard method of requirements gathering

• Understand the terminologies and possible implementation problems involved to create an alike software program.

The project does not deal with the actual implementation of the system but with the initial analysis and design. The result of this document is the requirements document that covers the complete solution based on Sommerville Software engineering techniques. All real world eventualities are not encountered for and some are left for further Development Cycles.

Abstract

An essential part of developing software or hardware applications involves the planning and gathering of information needed to estimate the duration, complexity, cost, workload, structure, organization and other parts that are included in a development process.

For every project there are some general or common parts in the process like requirements engineering. This document will mainly focus on the general definition of requirements and a study of a software product to support the requirements engineering.

Requirements engineering can be very different depending on the complexity of the system, the duration of the process. It is obvious that the more simple or established the project is and it might have a long duration than it will be very good to create a standard way of creating the requirements. Projects fitting into the dark section of the graph situated below can thus benefit of this program.

Furthermore we will base our assumptions on books that discuss the software engineering approach in depth so that common terminology can be easily transferred. When the tool is finished it should be able to help the software developer to faster finish the requirements engineering process by use of automated and guided procedures.

Time Schedule

Date	Time	Planning
Tuesday 3/09	11.00 – 12.00	Work division
Friday 5/09	15.00 – 17.00	Work division
Tuesday 10/09	11.00 – 12.00	Domain requirements
Friday 13/09	15.00 – 17.00	Domain requirements
Tuesday 17/09	11.00 – 12.00	Domain requirements
Friday 20/09	15.00 – 17.00	Domain requirements
Tuesday 24/09	11.00 – 12.00	Report design
Friday 27/09	15.00 – 17.00	Functional design
Tuesday 1/10	11.00 – 12.00	Functional design
Friday 4/10	15.00 – 17.00	Functional design
Tuesday 8/10	11.00 – 12.00	Functional design
Friday 11/10	15.00 – 17.00	Functional design
Tuesday 22/10	11.00 – 12.00	System Design
Friday 25/10	15.00 – 17.00	System Design
Tuesday 29/10	11.00 – 12.00	System Design
Friday 1/11	15.00 – 17.00	Dataflow design
Tuesday 5/11	11.00 – 12.00	Dataflow design
Friday 8/11	15.00 – 17.00	Dataflow design
Tuesday 12/05	11.00 – 12.00	User interface design
Friday 15/11	15.00 – 17.00	User interface design
Tuesday 19/05	11.00 – 12.00	Data Dictionary
Friday 22/11	15.00 – 17.00	Data Dictionary
Tuesday 26/05	11.00 – 12.00	Data Dictionary
Friday 29/11	15.00 – 17.00	Data Dictionary
Tuesday 3/12	11.00 – 12.00	Combining report parts
Friday 6/12	15.00 – 17.00	Combining report parts
Tuesday 10/12
Friday 6/12
Monday 16/12	09.00	Handing in of final report

List of Requirements

Here the complete list of requirements is shown. More details of these requirements will be covered in the different parts of this chapter. The requirements seems to exist off five large groups and we show them numbered. The general requirements are shown at first.

General requirements

1. The system has to run simultaneous on multiple computer and should thus be concurrent.
2. The system should keep track of dependencies between requirements.
3. Support a versioning system for requirements and log all changes made to the requirements.
4. Present a global status of the requirement process.
5. Create and print documentation.
6. Support a graphical presentation of the overall system structure.

Requirement analysis specification

7. Specify functional and non-functional requirements.
8. Support the requirements engineering process like in Sommerville Chapter 6

A description of these requirements can be found in the domain description, Chapter Error: Reference source not found Error: Reference source not found on page Error: Reference source not found.

1. Elicitation and analysis.
   1. The tool must support manipulation of domains
   2. The tool must have a dictionary
2. Requirements collection.
   1. The tool must have a facility for making a brainstorm.
   2. The tool must have facilities for making and editing an interview.
   3. It should be possible to draw use cases.
   4. The tool must support manipulation with requirements.
   5. The tool must support manipulation with tasks
3. Requirements classification.
   1. The tool should provide a facility for organizing the requirements.
   2. Requirements related to the same part of the system should be classified and linked together
   3. Searching for requirements, containing some elements of the work process should be possible.
   4. Interface for looking up domain information.
   5. Interface for making graphics (use case/ class diagrams / user interface etc. )
   6. It must be possible to manipulate services
4. Requirements conflict resolution.
   1. The CASE tool shall provide an option for editing in an existing requirement.
   2. It shall be possible to edit in both the user and system specification and the graphical representations linked to the requirement.
   3. A record should be kept of the last changes made.

   4. Comparing 2 or more requirements shall be possible.

   5. Deleting a requirement shall be possible.

   6. Linking requirements to different graphical representations shall be possible.

   7. It should be possible to find the relevant information about the source of a requirement.

   8. It shall be possible to relate similar requirements.

   9. The CASE tool shall provide a keyword search facility for quick retrieval of requirements.

   10. The CASE tool should provide easy access to the links and relations of a requirement.

   11. When two requirements essentially elaborate each other, it should be possible to merge them.

5. Requirements prioritization.
   1. The tool should enable the user to give a priority to each requirement
   2. The tool should check whether the prioritization is valid.
6. Requirements checking.
   1. Should provide a method of viewing status.
   2. Display a list of requirements
   3. View a requirement and all related information.
   4. Sign a requirement off as validated.
   5. Raise an issue to management if validation of a requirement cannot be accomplished

Requirement specification

9. Create Requirement specification
   1. Use structured language for the requirement specification.
   2. Allow a functional style.
   3. Include functional specifications.
   4. Make data definitions in the Bachus-Naur format.
   5. The CASE tool should provide an option for generating a standard requirements document according to different standards.
   6. It shall be possible customize the format and the content of the document.
   7. It shall be possible and easy to insert the requirements into the document
   8. Given a cluster of related requirements (e.g. requirements concerning the conflict resolution) these should automatically be inserted into the document.
   9. The tool must be able to define and specify both functional and non-functional requirements.

Requirement validation specification

A description of these requirements can be found in the domain description, Chapter Error: Reference source not found Error: Reference source not found on page Error: Reference source not found.

10. Use Requirement validation
    1. Validate like in Sommerville, figure 6.1.
    2. Include validation checks like in Sommerville, 6.3.
    3. The CASE tool should provide an option for reviewing the requirements.

    4. It should be possible to mark a requirement as checked.

    5. It should be possible to generate a printable document of the requirements with additional space in the vicinity of the requirements for adding comments and changes.

    6. Tools from the elicitation and analysis subsystem should be available when requirements are detected as being not correct.

    7. The CASE tool should provide an option for setting up Test-cases.

    8. COTS for analysing requirements expressed as system models in a formal notation already exist. These COTS should be implemented in the CASE tool as they will help to test for consistency.

Requirement management

A description of these requirements can be found in the domain description.

11. Manage the generation of requirement documents.
    1. Manage papers and documents.
    2. Create versioning system to track changes.
    3. Create a standard way for managing the distribution of the documents.
    4. Create Templates that can be used as standard documents.
12. The tool should be able to make a management plan.
    1. The tool should be able to create a plan to divide the tasks and the workload for the different parts of the system.
    2. The tool should be able to create milestones.
13. Allow requirement management.
    1. Use requirement management like in Sommerville, 6.
14. Use requirement change management like in Sommerville, 6.4.3.
    1. The tool should be able to produce a traceability matrix similar to the one used in Ian’s Somerville book page 143.
    2. The tool should provide means to trace the requirement source as such to identify the requirements created by different stakeholders.
    3. Given a requirement the tool should be able to find related requirements.
    4. Any stakeholder can submit a change to the requirements.
    5. Given a requirement the complete cost of changing the requirement can be calculated.
    6. A change requirement needs to be validated by the Stakeholders and the customers.

1. Services for the domain understanding

– Service: Create_Domain(string domain)

The Domain is constructed and initialized with an initial description

– Service: Select_Domain(int selection)

Select the domain from a list of domains.

Use the domain description, gather knowledge by different methods(interview, scenario,…)

Analyze and document the knowledge.

1. Non Functional requirements

   1. Performance and general requirements

Non-functional requirements are not concerned with the functions offered by the system but with the constraints on the system and the emergent properties. The non-functional requirements will therefore often have a greater impact on the system as a whole.

In the following it has been attempted to state as many of the non-functional requirements as possible in a quantitative manner. The non-functional requirements have been divided into the following three categories; product requirements, organizational requirements and external requirements.

Product requirements

1. The system will be running on a network and different clients will connect to the same master database.
2. The program should be able to run remote from common internet client computers where no spcific hardware is required.
3. The system has to be easy to use. Experienced software engineers should be able to use the system after a total of two hours training time.

After this training the average number of errors made by experienced users shall not exceed one per day.

4. The system should contain help functions to assist the end-user. There should be one help frame per user interface. This should improve the usability.
5. The help system should support the two types of help: ‘help, I’m in trouble’ and ‘help I want information’.
6. Browsing through the options of the CASE tool should be intuitive to minimize training time.
7. The user interface should be similar to other applications used in the company. The user interfaces could look something like the ones seen under the different functional requirements.
8. The CASE tool should provide graphical user interfaces for all operations.
9. The maximum storage occupied by the CASE tool should be small enough to comfortably fit into a standard PC.
10. On failure the system should give correct, precise and helpful error messages. System failure should be rare.

Organizational requirements

1. Java or C++ or C# should be used in the implementation as these are the preferred programming languages in the company STInc.

2. The system should support and use the processes from Sommerville’s Software Engineering.

3. The system should be delivered as a whole system and not as modules.

4. The system should be able to work with the database.

External requirements

The requirements document is to be delivered the 16 of December 2002.

1. Graphical user interfaces

Below are the different user interfaces for all parts of the tool.

Conclusion

Through the process of making the requirements document, different techniques from Sommervill’s software processes were used. The starting point was taken from the various documents supplied by STInc stating the general purpose of the system and what was wanted from it. It was necessary to elaborate on these general needs as they were not very detailed. As the needs from the different stakeholders were uncovered the process of transforming them into requirements statements, structuring them and detailing them was initiated.

As the CASE tool is gradually put into use in the company new requirements will with out a doubt appear and some requirements will have to be changed. These new requirements should be included in the requirements document under the existing categories.

Working with the software processes and the different techniques has been an ongoing learning process. As we worked on finding, describing and detailing the requirements our understanding of the domain and the customers needs improved and this lead to the discovery of new requirements.

When describing the overall processes Sommerville’s Software Engineering is really good, it also gives some good examples of techniques to be used. A lot of work has been spend in trying to integrate, find and structure the different methods that Sommerville uses to create a complete requirements document.

The process of finding out how to make the requirements document has been very educational.

Sommerville gives good examples of different types of requirements but you don’t get the overview e.g. the connections between the different types of requirements, the user interfaces and different graphical representations.

Through the work of making the requirements document it has been made even more obvious that a requirements engineering CASE tool is indeed a useful tool. It would have been helpful having had a CASE tool for assisting in the describtion and grouping of the different services.

If a CASE tool had been available in the course the outcome of this report would probably have been very different. The CASE tool would have given us some guidelines for working with the processes and the various definitions wouldn’t have been open for interpretation. It would have provided a predefined workflow and thereby less choices and ultimatly a job done in less time.

References

1. Software Engineering – An Engineering Approach

J. Peters, W. Pedrycz – ISBN 0-471-18964-2 (2000)

2. Software Engineering

Ian Sommerville – ISBN 0-201-39815-X (2001)

3. Human Computer Interaction

Jenny Preece – (Addison-Wesley) ISBN 0-201-62769-8

4. Software User Interface engineering

Morten Borup Harning – (Det Økonomiske Fakultet Handelshøjskolen I København) Ph.d.-serie 5.97 ISBN 87-593-8079-9 ISSN 0906-6934

5. User interface design: A Software Engineering perspective

Soren Lauesen