1. CHAPTER FOUR: Requirements Engineering.
   1. Functional and non-functional requirements
      1. Functional requirements
         1. * For a system describe what the system should. * Depend on the type of software being developed *Written in natural language in elicitation. *Describe funcionality or system services.
         2. Requirements
            1. Requirements imprecision
            2. Requirements completeness and consistency
      2. Non-functional requirements
         1. Classification
            1. Product requirements: Specify or constrain the runtime behavior of the software
            2. Usability requirements
            3. Efficiency requirements
            4. Dependability requirements
            5. Security requirementes
            6. Organizational requirements: Are broad system requirements derived from policies and procedures in the customer's and developer's organization
            7. Environmental requirements
            8. Operational requirements
            9. Developments requirements
            10. External requirements: This broad heading covers all requirements process.
            11. Regulatory requirements
            12. Ethical requirements
            13. Legislative requirements
         2. Implentation
         3. Goalds and requirements
         4. Metrics
      3. Dominian requirements
         1. ??
   2. Requirements engineering processes
      1. Elicitation and analysis: Discovering requirements by interacting with stakeholders.
      2. Specification: Converting these requirements into a standard form.
      3. Validation: Checking that the requirements actually define the system that customer wants.
      4. The activities are organized as an iterative process around a spiral
         1. SPIRAL MODEL
            1. Accommodates approaches to development where the requirements are developed to different level of delail.
            2. The number of iterations around the spiral, can vary so that the spiral can be exited after some or all of the user requirements have been elicited.
            3. Agile developments can be used instead of prototyping so that the requirements and the system implementation are developed together.
   3. Requirements elicitation
      1. Requirements elicitation techniques
         1. There are two fundamental approaches to requirements elicitation:
         2. 1. Interviewing, where you talk to people about what they do.
         3. 2. Observation or ethnograpy, where you watch people doing their job to see what artifacts they use.
      2. Stories and scenarios
         1. A scenario may include:
            1. A description of what the system and users expect when the scenario starts.
            2. A description of the normal flow of events in the scenario.
            3. A description of what can go wrong and how resulting problems can be handled.
            4. Information about other activities that might be going on at same time.
            5. A description of the system state state when the scenario ends.
   4. Requirements specification
      1. Natural language specification: It is a expressive, intuitive, and universal. It is also potentially vague and abigous, and its interpretation depents on the background of the reader/
      2. Structured specification: Is a way of writting system requirements where requirements are written in a standar way rather than as free-form text. Included:
         1. 1. A description of the function or entity being specified.
         2. 2. A description of its inputs and the origin of these inputs.
         3. 3. A description of its outputs and the destination of these outputs.
         4. 4. Information about the information needed for the computation or other entities.
         5. 5. A description of the action to be taken.
         6. 6. A description of the side affects (if any) of the operation.
      3. Use cases: Are a way of describing interactions between users and a system using a graphical model and structured text. Are documented using a high-level use case diagram.
      4. The software requirements document (SRS): Is an official statement of what the system developers should implements. The requirements document is likely to be long and detailed.
      5. SRS
         1. Scope
         2. Purpose
         3. People
         4. Budget
         5. Investigation
   5. Requirements validation
      1. Validity chacks
         1. These chack that the requirements reflect the real needs of system users.
      2. Consistency chacks
         1. Requirements in the document should not conflict.
      3. Completeness chacks
         1. The requirements document should include requirements that define all functions and the constraints intended by the user.
      4. Realism checks
         1. These checks should also take account of the budget and schedule for the system developtent.
      5. Verifiability
         1. To reduce the potencial for discute between customer and contractor, system requirements should always be written so that they are verificable.
   6. Requirements change
      1. Requirements management planning
         1. 1. Requirements identification: Each requirement must be uniquely identified so that ir can be cross-referenced.
         2. 2. A change managements process: This is the set od activities that assess the impact and cost of change.
         3. 3. Traceability policies: These policies define the relationships between each requirement and between the requirements and the system desing that should be recorded.
         4. 4. Tool support: Requirements managements involves the processiong of large amounts of information about the requirements.
      2. Requirements change management
         1. 1. Problem analysis and change specification: The process stats with an identified requirements problem or, sometimes, with a specific change proposal.
         2. 2. Change analysis and costing: The effect of the proposed change is assessed using traceability information and general knowledge of the system requirements.
         3. 3. Change implementation: The requirements document and, where necessary, the system desing and implementation, are modified.
2. Requirements
   1. Are a descriptions of the services that a system should provide and the constraints on its operation.
3. New requirements have to be established and changes made to the system. This delays system delivery and increases COSTS.
4. What is Elicitation?
5. Are the description of the system services and constraints that are generated during the requirements process
6. Requirements Engineering
   1. Are the process of finding out, analyzing, documenting, and checking the needs of customers for a system.
   2. Sistematic process. What other thing?
      1. Because embole diferent activities.
      2. -Elicitation -Especification -Validation
   3. Types of requirements
      1. User requirements: High abstract requirements.
      2. System requirements: More precise detailed of what the system should
      3. The difference is the ambiguos.
7. Stackeholders
   1. Direct: Impact directly.
   2. Indirect: Need to know what is going on with the system or project.
8. Floating Topic
9. Are requirements that are not directly concerned with the specific services delivered by the system to its users.
10. Are statements of services the system should provide. The functional requirements may also explicitly state what the system should not do.