Lecture 5 Requirements Capture
In This Lecture You Will Learn:
- Objectives of Requirements Capture
- Why Requirements Capture?
- User Requirements
- User Involvements
- Documenting Requirements
- Documentation Standards
Objectives of Requirements Capture
- The distinction between the current and required system
- When and how to apply the 5 major fact-finding techniques
- The need to document requirements
Why Requirements Capture?
- Identifying what a new system should be able to do
- The user requirements can be classified in different ways
- Each of the fact-finding techniques has advantages and disadvantages and its appropriateness for different situations.
User Requirements
- Understanding both of the overall objectives of the business
- Individual users of the system are trying to achieve
- Information about what people are doing is gathered and documented
- Problems with and inadequacies of the current system
Current System
- The existing system may be manual system, based on paper documents, forms and files, it may already be partly computerized
- It is important that the analysts, gathering information as one of the first steps in developing a new system, gains a clear understanding of how the existing system works
- A case can be made for investigating the existing system:
- a) Some of the functionality of the existing system will be required in the new system
- b) Some of the data in the existing system is of value and must be migrated into new system
- c) Technical documentation of existing computer system may provide details of processing algorithms that will be needed in the new system
- d) The existing system may have defects which we should avoid in the new system
- e) To understand the organization in general
- f) Parts of the existing system might retained
- g) Understand how people use the system at present
New Requirements
Reasons for changes:
- Rapidly Changes - based on economies around the world change dramatically and at short notice, the fortunes of large companies which may be organization’s suppliers, customers or competitors can be transformed overnight.
- New technologies are introduced which change production process, distribution networks and the relationship with the introduce legislation that has an impact on the way that business is conducted
- Internal factors to grow and change the ways in which they operate and this too provides a motivation for the development of new IS
- Whether we are investigating the working of existing system or the requirements for the new system, the information system you gather will fall into one of the 3 categories:
- Functional requirements, non-functional requirements and usability requirements.
Functional Requirements
- Describe what the system does or is expected to do, often referred to as its functionality.
- In OOAD, use case is used to document the functionality of the system.
- Functional requirements include:
- a) Descriptions of the inputs into the system from paper forms and documents, from interactions between people such as telephone calls and other systems
- b) Details of the processing which the system will be required to carry out
- c) Details of the outputs that are expected from the system in the form of printed documents and reports, screen displays and transfers to other system.
- d) Details of data that must be held in the system
Non-Functional Requirements
- Describe aspects of the system that are concerned with how it provides the functional requirements
- Items included here:
- a) Performance criteria such as desired response times for updating data in the system or retrieving data from the system
- b) Anticipated volumes of data, either in terms of throughput or of what must be stored
- c) Security considerations
Usability requirements
- To ensure that there is a good match between the system that is developed and both the users of that system and the tasks that they will undertake when using it.
- Gather the following types of information:
- Characteristic of the users who will use the system
- Goals to achieve (tasks undertake)
- Situations which could arise during system use
- Acceptance criteria
User Involvement
- A variety of stakeholders:
- senior management—with overall responsibility for the organization
- financial managers—who control budgets
- managers of user departments
- representatives of users of the system
- Different roles:
- subjects of interviews
- representatives on project committees
- evaluators of prototypes
- testers
- as trainees on courses
- end-users of new system
Documenting Requirements
- Documentation should follow organizational standards
- CASE tools that produce UML models maintain associated data in a repository
- Some documents will need separate storage in a filing system:
- interview notes
- copies of existing documents
- minutes of meetings
- details of requirements
- Documents should be kept in a document management system with version control
- Use use cases to document functional requirements
- Maintain a separate requirements list
- Review requirements to exclude those that are not part of the current project
Documentation Standards
- IS professionals need to record facts about the organization they are studying and its requirements
- Standards are important as they promote communication in the same way as a common language
- In here, we will be using UML (unified Modeling language) since it is used in the developing industry.
- UML consists of a graphical language represent the concepts that we require in the development of an object-oriented information system.
- Diagrams in a modeling language such as UML also conform to agree standards. Diagrammatical models are used extensively by system analysts and designers in order to:-
- a) communicate ideas
- b) generate new ideas and possibilities
- c) test ideas and make predictions
- d) understand structures and relationships
- Computer-Aided Software Engineering (CASE) tools are used to draw these diagrams and to maintain the associated about the various things that are shown in the diagrams.
- Modeling techniques should aid:
- a) Simplicity of representation - only showing what needs to be shown
- b) Internal consistency - within a set of diagrams
- c) Completeness- showing all that needs to be shown
- d) Hierarchical representation - breaking the system down and showing more detail such as lower level
Summary
- Objectives of Requirements Capture
- Why Requirements Capture?
- User Requirements
- User Involvements
- Documenting Requirements
- Documentation Standards