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.
            1. Types of interview
            2. Closed
            3. Open
            4. In practice
            5. Formal and Informal
         3. 2. Observation or ethnograpy, where you watch people doing their job to see what artifacts they use.
            1. Scope of ethnography
            2. identify new features that should be added to a system.
            3. Focused ethnography
            4. Combines ethnography with prototyping
      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. Writting a system 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.
            1. Probles
            2. Lack of clarity
            3. Precision is difficult without making the documnet difficult to read.
            4. Requirements confusion
            5. Fuctional and non-fuctional requirements tend to be mixed-up.
            6. Requirements amalgamation
            7. Several different requirements maybe expressed together.
         2. Structed natural language
         3. Design description languages
         4. Graphical notations
         5. Mathematical specification
         6. Guidelines for writing requirements
            1. Invent a standar format and use it for all requirements
            2. Use language in a consistent way.
            3. Use text highting
            4. avoid the use of computer jargon
            5. Include an explanation
      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.
         7. Tabular specification
            1. Subtopic 1
            2. Subtopic 2
      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. Requirements and design
         1. requirements should state what the system should do and the design should describe how is
      6. SRS
         1. Scope
         2. Purpose
         3. People
         4. Budget
         5. Investigation
         6. Glosary
   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. Are requirements that are not directly concerned with the specific services delivered by the system to its users.
9. Are statements of services the system should provide. The functional requirements may also explicitly state what the system should not do.
10. Floating Topic
11. The problem about this tecnical is the ambiguity. Formal is Documents and Informal is only elicitation. Are not good for understanding domain requirements.
12. The difference between interviewing and stories and scenarios: techniques
13. Writing in a requirements document (SRS).