1. Requirements Engineering
   1. Are the description of the system services and constraints that are generated during the requirements process
   2. Are the process of finding out, analyzing, documenting, and checking the needs of customers for a system.
   3. Sistematic process. What other thing?
      1. Because embole diferent activities.
      2. -Elicitation -Especification -Validation
   4. 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.
2. 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. Are statements of services the system should provide. The functional requirements may also explicitly state what the system should not do.
         3. Requirements
            1. Requirements imprecision
            2. Requirements completeness and consistency
      2. New requirements have to be established and changes made to the system. This delays system delivery and increases COSTS.
      3. 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
         5. Are requirements that are not directly concerned with the specific services delivered by the system to its users.
      4. 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
            6. The problem about this tecnical is the ambiguity. Formal is Documents and Informal is only elicitation. Are not good for understanding domain requirements.
         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. The difference between interviewing and stories and scenarios: techniques
   5. 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. Writing in a requirements document (SRS).
      4. 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.
      5. 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.
      6. Requirements and design
         1. requirements should state what the system should do and the design should describe how is
      7. SRS
         1. Scope
         2. Purpose
         3. People
         4. Budget
         5. Investigation
         6. Glosary
   6. 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.
   7. 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.
3. Requirements
   1. Are a descriptions of the services that a system should provide and the constraints on its operation.
   2. Stackeholders
      1. Direct: Impact directly.
      2. Indirect: Need to know what is going on with the system or project.
4. Difference Between
   1. User Case
      1. Waterful Spiral
   2. User Story
      1. Agile
5. Software Processes
   1. Software Process Models
      1. The general process models that I cover here are:
         1. The Waterfall Model
            1. This takes the fundamental process activities of specification, development, validation, and evolution and represents them as separate process phases such as requirements specification, software design, implementation, and testing.
            2. Activities:
            3. Requirements definition
            4. The system's services, constraints, and goals are established by consultation with system users.
            5. They are then defined in detail and serve as a system specification
            6. System and software design
            7. System design
            8. Process allocates the requirements to either hardware or software system.
            9. Software design
            10. Involves identifying and describing the fundamental software system abstractions and their relationships.
            11. Implementation and unit testing
            12. The software design is realized as a set of programs or program units.
            13. Unit testing involves verifying that each unit meets its specification.
            14. Integration and system testing
            15. The individual program units or programs are integrated and tested as a complete system to ensure that the software requirements have been met.
            16. After testing, the software system is delivered to the customer.
            17. Operation and maintenance
            18. This is the longest life - cycle phase.
            19. Maintenance involver correcting errors that were not discovered in earlier stages of the life cycle.
            20. During design, problems with requirements are identified. During Coding design problems are found, and so on.
            21. Types of system
            22. Embedded systems
            23. Where the software has to interface with hardware systems.
            24. Critical systems
            25. Where there is a need for extensive safety and security analysis of the software specification and design.
            26. The specification and design documents must be complete so that this analysis is possible.
            27. Safety related problems in the specification and design are usually very expensive to correct at the implementation stage.
            28. Large software systems
            29. That are the part of broader engineering systems developed by several partner companies.
            30. Problems
            31. Mostly used for large systems enginnering projects.
            32. Change limited during the design process.
            33. Is appropiate when the requirements are well - understood.
            34. Benefits
            35. The cost od acoommodating changing customer requirements is reduced.
            36. It is easiers to ger cutomer feedback on the development work that has been done.
            37. More rapid delivery and deployment of usedul software to the customer is possible
         2. Incremental Development
            1. This approach interleaves the activities of specification, development, and validation. The system is developed as a series of versions (increments), with each version adding functionality to the previous version.
            2. Is based on the idea of developing an initial implementation, getting feedback from users and others, and evolving the software through several versions until the required system has been developed.
            3. Major advantages over the waterfall model
            4. The cost of implementing requirements changes is reduced. The amount of analysis and documentation that has do be redone is significantly less than is required with the waterfall model.
            5. It's easier to get customer feedback on the development work that has been done. Customers can comment on demonstrations of the software and see how much has been implemented.
            6. Early delivery and depolyment of useful software to the customer is possible, even if all of the functionality has not been included. Customers are able to use and gain value from the software earlier than is possible with a waterfall process
            7. Two problems:
            8. The process is not visible. Managers need regular deliverables to measure progress.
            9. System structure tends to degrade as new increments are added. Regular change leads to messy code as new functionality is added in whatever way is possible.
         3. Integration and configuration
            1. approach relies on the availability of reusable components or systems. The system development process focused on configuring these components for use in a new setting and integrating them into a system.
            2. cost
            3. Examples
            4. Hardware
            5. Software
            6. Three types of software components are frequently reused:
            7. Stand - alone application systems
            8. Collections of objects
            9. Web services
            10. The stages in this process are:
            11. Requirements specification: The initial requirements for the system are proposed.
            12. Software discovery and evaluation: given an outline of the software requirements, a search is made for components and systems that provide the functionality required.
            13. Requirements refinement: The requirements are refined using information about the reusable components and applications that have been discovered. Where modifications are impossible.
            14. Application system configuration: If an off-the-shelf application system that meets the requirements is a available.
            15. Component adaptation and integration: if there is no off-the-shelf system, individual reusable components may be modified and new components developed.
            16. Reuse is now the standar approach for building many types of business system
            17. Reuse
            18. It´s the process of creating software systems from existing software.
         4. RUP
            1. Is a flexible model that can be instantiated in different ways to create processes that resemble any of the general process models discussed here
      2. Is a simplified representtion od software process.
      3. These generic models are high-level, abstract descriptions of software processes that can be used to explain different approaches to software development.
   2. Process Activities
      1. Software specification
         1. Activities
            1. Requirements elicitation and analysis
            2. This is the process of deriving the system requirements through observation of existing systems, discussions with potential users and procurers, task analysis, and so on.
            3. These help you understand the system to be specified.
            4. Requirements specification
            5. Is the activity of translating the information gathered during requirements analysis into a document that defines a set of requirements.
            6. Requirements validation
            7. This activity checks the requirements for realism, consistency, and completeness.
            8. Errors in the requirements document are inevitably discovered
      2. Software design and implementation
         1. Activities:
            1. Architectural design
            2. Where you identify the overall structure of the system/
            3. Database design
            4. Where you design the system data structures and how these are to be represented in a database.
            5. Interface design
            6. Where you define the interfaces between system components
            7. This interface specification must be unambiguous.
            8. Component selection and design
            9. Where you search for reusable components and, if no suitable components are available, design new software components.
      3. Software validation
         1. Subtopic 2
         2. Testing Stages
            1. Component testing
            2. Individual components are tested independently.
            3. Components may be functions or objects or coherent groupings or these entities.
            4. System testing
            5. Testing of the system as a whole.
            6. Testing of emergent roperties is particularly important.
            7. Customer testing
            8. Testing with customer data to check that the system meets the customer's needs.
      4. Software evolution
         1. Subtopic 1
         2. Subtopic 2
         3. Subtopic 3
   3. Coping with change
      1. Change is inevitable in all large software projects.
         1. business
         2. new technologies
         3. changing
      2. Two related approaches may be used to reduce the costs of rework:
         1. Change anticipation:
            1. Where the software process includes activities that can anticipate or predict possible changes before significant rework is required.
            2. Example: Prototype
         2. Change tolerance:
            1. Where the process and software are designed so that changes can be easily made to the system.
      3. Two ways of coping with change and changing system requirements:
         1. System prototyping: where a version of the system or part of the system is developed quickly to check the customer's requirements and the feasibility of design decisions.
         2. Incremental delivery: Where system increments are delivered to the customer for comment and experimentation.
      4. Prototyping
         1. A software prototype can be used in a software development process to help anticipate changes that may be required:
            1. In the requirements engineering process, a prototype can help with the elicitation and validation of system requirements.
            2. In the system design engineering process, a prototype can be used to explore software solutions and in the development of a used interface for the system.
         2. Throw-away prototypes
      5. Incremental delivery
         1. Incremental delivery has a number of advantages
            1. Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments.
            2. Customers don't have to way until the entire system is delivered before the can gain value from it
            3. The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system.
            4. As the highest priority services are delivered first and later increments then integrated, the most important system services receive the most testing.
         2. There are problems with incremental delivery.
            1. Most systems require a set of basic facilities that are used by different parts of the system.
            2. The essence of iterative processes is that the specification
         3. Incremental
            1. Developments
            2. Subtopic 1
            3. Subtopic 2
            4. Subtopic 3
            5. Delivery
            6. Subtopic 1
            7. Subtopic 2
            8. Subtopic 3
      6. Coping with changing requirements
         1. System prototyping
         2. Incremental delivery
         3. freeze requirements.
   4. Process Improvement
      1. change the process for reduce time and cost.
      2. Two quite different approaches improvement and change are used:
         1. The process maturity approach
            1. Which has focused on improving process and project management and introducing good software engineering practice into an organizarion
            2. The level of process reflects the extent to which good technical and management practice has been adopted in organizational software.
            3. The primary goals of this approach are improved product quality and process predictability.
         2. The agile approach
            1. Which has focused on iterative developmen and the reduction of overheads in the software process.
            2. Are rapid delivery of functionality and responsiveness to changing customer requirements.
            3. Focus un changes for customers.
      3. The stages in this process are:
         1. Process measurement
            1. You measure one or more attributes of the software process or product.
            2. These measurements form a baseline that helps you decide if process improvements have been effective.
         2. Process analysis
            1. The current process is assessed, and process weaknesses and bottlenecks are identified.
            2. Process models (Process maps): that describe the process may be developed during this stages.
         3. Process change
            1. Process changes are proposed to address some of the identified process weaknesses.
      4. Process metrics
         1. time taken for process activiyies to be complete
         2. resouces required for processes or activities
         3. number of occurrences of a particular event.
      5. The levels in the process maturity model are:
         1. Initial
            1. The foals associated with the process area are satisfied, and for all processes the scope of the work to be performed.
         2. Managed
            1. the goals associated with the process area are met, and organizational policies are in place that define when each process should be used.
         3. Defined
            1. this level focuses on organizational standardization and deployment of processes.
         4. Quantitatively managed
            1. there is an organizational responsibility to use statistical and other quantitative methods to control subprocesses.
         5. Optimizing
            1. the organization must use the process and product measurements to drive process improvements.
      6. The process improvement is a cycle. Long activity.
   5. Extra concepts
      1. Four fundamental software engineering activities:
         1. Software Specification: the funcionality of the software and constraints on its operation must be defined.
         2. Software Development: the software to meet the specification must be produced.
         3. Software Validation: the software must be validated to ensure that it does what the customer wants.
         4. Software Evolution: the software must evolve to meet changing customer needs.
      2. Difference between VALIDATION and VERIFICATION
         1. Validation
            1. Checks the process.
         2. Verification
            1. Checks the especifications
      3. Difference
         1. Waterfall
            1. Large project
         2. Incremental
            1. More rapid.
      4. Artefact
         1. Subtopic 1
      5. CRUD
         1. Create
         2. Read
         3. Update
         4. Delete
6. UML
7. Creating Use Case Diagrams
   1. A Use Case diagram shows the relationships between actors and the goals they wish to achieve.
   2. provides a visual representation of the system
   3. can be assigned priorities based on business need, complexity, and dependency on other use cases.
   4. UML Diagram Categories
      1. Actors are simply roles. Any physical person, system, or device can assume multiple roles.
      2. alternative style is to draw an association line between the Receptionist actor and the Manage Reservation use case as the Receptionist can manage reservations as well.
   5. Actors
      1. An actor is a role that a user plays with respect to the system
      2. An Actor models a type of role played by an entity that interacts with the subject
      3. represent roles played by human users, external hardware, or other subjects.
      4. Anyone or anything that is external to the system and interacts with the system is an actor
      5. Three classes of actors
         1. People
         2. External systems or devices
         3. time
      6. Subcategorized
         1. primary actors
            1. participate for the entire duration of the use case.
         2. secondary actors
            1. participate for only part of the duration of the use case.
   6. use cases
      1. The specification of a sequence of actions, including variants, that a system can perform
      2. describes an interaction between an actor and the system to achieve a goal
      3. use case encapsulates a major piece of system behavior with a definable outcome
         1. provides a visual encapsulation of all of the detailed actions involved in a major system behavior
      4. A use case is represented as an oval with the use case title in the center.
   7. System Boundary
      1. A Use Case diagram may also be drawn without a system boundary.
   8. Use case Associations
      1. the participation of an actor in a use case.
      2. association is represented by a solid line usually with no arrowheads.
   9. time of discovery of use cases depends upon the development process
   10. identifying additional use cases
       1. Non-iterative process
          1. this is a resource-intensive task and is rarely completely accurate.
          2. You ideally need to discover all of the remaining use case titles, bringing the total to 100 percent
       2. iterative /incremental development process
          1. Discover a total of 80 percent of the use case titles in the next few iterations for 20 percent of the effort.
          2. Discover the remaining 20 percent of use cast titles in the later iterations for minimal effort.
   11. Use case elaboration
       1. During the meeting with the other stakeholders, you will discover many more use cases that you can add to the diagram.
       2. a use case might describe a business function that includes several related workflows
       3. Typically, managing an entity implies being able to Create, (Retrieve), Update, and Delete an entity (so called, CRUD operations).
   12. analyzing inheritance patterns
       1. inheritance
          1. An actor can inherit all of the use case associations from the parent Actor
          2. A use case can be subclassed into multiple, specialized use cases.
          3. An actor can inherit all of the use case associations from the parent actor.
   13. Use case specialization
       1. A use case can be subclassed into multiple, specialized use cases.
       2. are usually identified by significant variations in the use case scenarios.
       3. The base use case may be marked as abstract, in which case you cannot instantiate the base use case.
   14. Analyzing use case dependencies
       1. One use case (a) includes another use case (i)
          1. This means that the one use case (a) requires the behavior of the other use case (i) and always performs the included use case.
       2. One use case (e) can extend another use case (b).
          1. This means that the one use case (e) can (optionally) extend the behavior of the other use case (b).
       3. The include dependency enables you to identify behaviors of the system that are common to multiple use cases.
       4. This dependency is drawn with a dependency arrow, and includes the «include» stereotype label.
       5. review the scenarios for sequences of behavior that involve an external actor (system or device
       6. The extend dependency enables you to identify behaviors of the system that are not part of the primary flow, but exist in alternate scenarios.
          1. his dependency is drawn with a dependency arrow, an «extend» stereotype label, and an additional label that identifies the “extension point.
   15. packaging the use case views
       1. software development would need more use cases than could be viewed at one time