Prep in SE: 1.

Requirements engineering (RE) refers to the process of formulating, documenting and maintaining software requirements[1] and to the subfield of Software Engineering concerned with this process. The first use of the term 'requirements engineering' was probably in 1979 in a TRW technical report [2] but did not come into general use until the 1990s with the publication of an IEEE Computer Society tutorial [3] and the establishment of a conference series on requirements engineering. In the waterfall model,[4] requirements engineering is presented as the first phase of the development process. Later software development methods, including the Rational Unified Process, Extreme Programming and Scrum assume that requirements engineering continues through the lifetime of a system. 2. The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements. However, there are a number of generic activities common to all processes Requirements elicitation; Requirements analysis; Requirements validation; Requirements management. 3. Different elicitation techniques Prototyping Interviewing Brainstorming Rapid prototyping is a high level elicitation technique that is helpful in overcoming articulation and communication barriers. Rapid prototype is a software that incorporates much of the functionality of the target product but omits aspects invisible to the client Brainstorming Group technique for generating ideas Allows people to suggest and explore ideas in an atmosphere free of criticism and judgment Overcomes cognitive limitations and communication barriers Stimulates imaginative thinking Helps to build a more complete picture Helps to avoid tendency to focus too narrowly too soon Provides more comfortable social setting Interviewing Used for eliciting detailed information from an individual For the small projects may be used as the only requirement elicitation technique For large projects usually a part of some high-level elicitation technique

 Interviewing is not simply a matter of asking questions; it requires development of some general social skills, the ability to listen, and knowledge of a variety of interviewing tactics Overcomes articulation problems and communication barriers 4. An example of a functional requirement would be that a system must send a an email whenever a certain condition is met (e.g. an order is placed, a customer signs up, etc). A related non-functional requirement for the system may be that emails should be sent with a latency of no greater than 12 hours from such an activity. The functional requirement requirement is describing the behavior of the system as it relates to the system's functionality. The non-functional requirement elaborates a performance characteristic of the system. Typically non-functional requirements fall into areas such as:

Accessibility Capacity, current and forecast Compliance Documentation Disaster recovery Efficiency Effectiveness Extensibility Fault tolerance Interoperability Maintainability Privacy Portability Quality Reliability Resilience Response time Robustness Scalability Security Stability Supportability Testability

Non-functional requirements are sometimes defined in terms of metrics (something that can be measured about the system) to make them more tangible. Non-functional requirements may also describe aspects of the system that don't relate to it's execution, but rather to it's evolution over time (e.g. maintainability, extensibility, documentation, etc). 5. Validation - to establish the fitness or worth of a software product for its operational mission.

Nordtest 01x699b Method of Software Validation Page 1 of 13 Software life cycle model Abstract Validation is the confirmation by examination a nd the provision of objective evidence that the particular requirements for a specific intended use are fulfilled [5]. Thus, validation of software is not just testing. Requirements must be specified and ev idence covering the intended use must be provided. This method recommends a working strategy based on a common software life cycle model and presents the validation problems in a clear and systemat ic way. This method will help to establish documented evidence, which provides a high degree of assurance that the validated software product will consistently produce results meeting the predet ermined specifications and quality attributes. Phase 1 Requirements and system acceptance test specification Input Output Functionality / limitations, defaults, security Platform / system requirements Special requirements / risk analysis. Preparation of system acceptance test Service and maintenance / phase out Phase 2 Design and implementation process Design and development planning Design input / analysis of requirements Design output / coding and implementation Design verification Design changes / judgement and action Phase 3 Inspection and testing Preparation of test plan Inspection of documents / source code Testing and acceptance Phase 4 Precautions Registration, correction, and workaround of detected and known anomalies in devices, environment, and the software product itself Phase 5 Installation and system acceptance test

Preparation of installation procedure Testing the installation procedure System acceptance test and approval Phase 6 Performance, servicing, maintenance, and phase out Changes Problem identification and solution Functional maintenance Performance improvement Upgrade to new versions Phase out / analysis of consequences 6. Product vision: aligns all stakeholders in a common direction Project scope: identifies what portion of the ultimate long-term product vision the current project will address. The vision applies to the product as a whole and will change relatively slowly. Scope is more dynamic than vision. 7. Software analysis patterns or analysis patterns in software engineering are conceptual models, which capture an abstraction of a situation that can often be encountered in modelling. An analysis pattern can be represented as "a group of related, generic objects (meta-classes) with stereotypical attributes (data denitions), behaviors (method signatures), and expected interactions dened in a domain-neutral manner." [1]

8. In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in UML as an "actor") and a system, to achieve a goal. The actor can be a human or an external system. In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML or as contractual statements. How to construct:

Collect information sourcesHow am I supposed to know that? Identify potential actorsWhich partners and customers use the goods and services of the business system? Identify potential business use casesWhich goods and services can actors draw upon?

Connect business use casesWho can make use of what goods and services of the business system? Describe actorsWho or what do the actors represent? Search for more business use casesWhat else needs to be done? Edit business use casesWhat actually has to be included in a business use case? Document business use casesWhat happens in a business use case? Model relationships between business use casesWhat activities are conducted repeatedly? Verify the viewIs everything correct?

9.