1. 4.1 Functional and non-functional requirements
1.1. 4.1.1 Functional requirements
1.1.1. Describes: 1. Functionality 2. System service
1.1.2. Depends on: 1. type of software 2. expected users 3. type of system where the software is used.
1.1.3. Functional user requirements: high-level statements of what the system should do
1.1.4. Functional system requirements: describe the system services in detail.
1.1.5. Requirements imprecision
1.1.5.1. Avoid problem
1.1.5.1.1. e.g: 1. User intention – search for a patient name across all appointments in all clinics. 2. Developer interpretation – search for a patient name in an individual clinic. User chooses clinic then search.
1.1.6. Requirements completeness and consistency
1.1.6.1. Complete: They should include descriptions of all facilities required.
1.1.6.2. Consistent: There should be no conflicts or contradictions in the descriptions of the system facilities.
1.2. 4.1.2 Non-functional requirements
1.2.1. Defines: 1.system properties 2. constraints
1.2.2. * Non-functional requirements may be more critical than functional requirements. If these are not met, the system may be useless.
1.2.3. Types of nonfunctional requirement
1.2.3.1. Product requirements
1.2.3.1.1. Usability requirements
1.2.3.1.2. Efficiency requirements
1.2.3.1.3. Dependability requirements
1.2.3.1.4. Security requirements
1.2.3.2. Organizational requirements
1.2.3.2.1. Environmental requirements
1.2.3.2.2. Operational requirements
1.2.3.2.3. Development requirements
1.2.3.3. External requirements
1.2.3.3.1. Regulatory requirements
1.2.3.3.2. Ethical requirements
1.2.3.3.3. Legislative requirements
1.2.4. Non-functional requirements implementation
1.2.4.1. *Non-functional requirements may affect the overall architecture of a system rather than the individual components. * For example, to ensure that performance requirements are met, you may have to organize the system to minimize communications between components. * A single non-functional requirement, such as a security requirement, may generate a number of related functional requirements that define system services that are required. * It may also generate requirements that restrict existing requirements.
1.2.5. Non-functional classifications
1.2.5.1. Product requirements: * Requirements which specify that the delivered product must behave in a particular way e.g. execution speed, reliability, etc.
1.2.5.2. Organizational requirements: * Requirements which are a consequence of organizational policies and procedures e.g. process standards used, implementation requirements, etc.
1.2.5.3. External requirements: * Requirements which arise from factors which are external to the system and its development process, e.g. interoperability requirements, legislative requirements, etc.
2. 4.2 software requirements document
2.1. Official statement of what is required of the system developers.
2.2. User of requirements document
2.2.1. System customers
2.2.2. Managers
2.2.3. System engineers
2.2.4. System test engineers
2.2.5. System maintenance engineers
3. 4.5 Requirements elicitation and analysis * Sometimes called requirements elicitation or requirements discovery. * Involves technical staff working with customers to find out about the application domain, the services that the system should provide and the system’s operational constraints. *May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders. *Software engineer s work with a range of system stakeholders to find out about the application domain, the services that the system should provide, the required system performance, hardware constraints, other systems, etc.
3.1. Problems of requirements analysis
3.1.1. The Stakeholders don't know what they really want.
3.1.2. Stakeholders express requirements in their own terms.
3.1.3. Different Stakeholders may have confliction requirements.
3.1.4. Organizational and political factors may influence the systems.
3.1.5. The requirements change during the analysis process. New stakeholder may emerge and the business environment may change.
3.2. The requirements elicitaion and analysis process activites
3.2.1. Requirements discovery
3.2.1.1. Interacting with stakeholders to discover their requirements.
3.2.2. Requirements classification and organization
3.2.2.1. Groups related requirement and organizes them into coherent cluster
3.2.3. Prioritization and negotiation
3.2.3.1. Prioritizing requirements and resolving requirements conflicts.
3.2.4. Requirements Specifications
3.2.4.1. Requirements are documented and input into the next round of spiral
3.3. Requirements discovery
3.3.1. The process of gathering information about the required and existing systems and distilling the user and system requirements from this information.
3.3.2. Interaction is with system stakeholders from managers to external regulators
3.3.3. System normally have a range of stakeholders
3.4. Stakeholder in the MHC-PMS
3.4.1. Patient whose information is recorded in the system
3.4.2. Doctors who are responsible for assessing and treating patients
3.4.3. Nurses who coordinate the consultations with doctors and adminnister some treatments
3.4.4. Medical receptionist who manage patients's appointments
3.4.5. IT staff who are responsible for installing and maintaining the system
3.4.6. A medical ethics manager who must ensure that the system meets current ethical guidelines for patient care
3.4.7. Health care managers who obtain management information from the system
3.4.8. Medical records staff who are responsible for ensuring that system information can be maintained and preserved, and tthat record keeping procedures have been properly implemented
4. 4.7 REQUIREMENTS MANAGEMENT
4.1. - The process of managing changing requirements during the requirements engineering process and system development.
4.1.1. REQUIREMENT CHANGE MANAGEMENT
4.1.1.1. 1. PROBLEM ANALYSIS AND CHANGE SPECIFICATION
4.1.1.2. 2. CHANGE ANALYSIS AND COSTING
4.1.1.3. 3. CHANGE IMPLEMENTATION
4.1.2. KEY POINTS
4.1.2.1. 1. Requirements
4.1.2.2. 2. Functional Requirements
4.1.2.3. 3. Not functional Requirements
4.1.2.4. 4. Software requirement documents
4.1.2.5. 5. Requirement egineering process
4.1.2.6. 6. Requirement validation
4.1.2.7. 7. Requirement management
5. 4.6 Requirements validation
5.1. * Concern with demonstrating that the requirements define the system that the customer really wants.
5.2. * Requirements error costs are high so validation is very important.
5.3. Requirements checking: * Validity * Consistency * Completeness * Realism * Verifiability
5.4. Requirements validation techniques: * Requirements reviews * Prototyping * Test-case generation
6. 4.3 Requirements specification
6.1. requirements should state what the system should do and the design should describe how it does this.
6.2. user requirements - have to be understandable by end-users and customers who do not have a technical background
6.3. system requirements- more detailed requirements and may include more technical information
6.3.1. Natural language
6.3.2. structured natural language
6.3.3. design description languages
6.3.4. graphical notations
6.3.5. mathematical specifications