SDLC Processes and Requirements Engineering - Tagged.pdf

Software Life Cycle Processes Requirements Engineering CSPC 541 Fall 2024 Prof. Son Nguyen Welcome – Week 2  Attendance/Sign In  Software Life Cycle Processes  Class Discussion  Requirements Engineering  Coming Ne...

Software Life Cycle Processes Requirements Engineering CSPC 541 Fall 2024 Prof. Son Nguyen Welcome – Week 2  Attendance/Sign In  Software Life Cycle Processes  Class Discussion  Requirements Engineering  Coming Next  Q&A  References 1. Practical Software Maintenance, Thomas M. Pigoski, 1996, John Wiley & Sons, Inc., New York, NY. 2. Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman 3. The Process of Architecting, Peter Eeles, Peter Cripps  Polls How was your first week of classes in two words? a) Awesome and interesting b) Boring and slow c) Confusing and hot! d) Interesting and new e) /etc and etc.  5 Can you spot three differences in 10”? https://www.semrush.com/blog/most-searched-keywords-google/  6 Can you spot three differences in 10”? https://www.semrush.com/blog/most-searched-keywords-google/  Software Development Life Cycle (SDLC) 7 Have you heard of SDLC? What are the phases of SDLC?  Software Life Cycle Software Development Life Cycle (SDLC) – A 1. Planning series of steps, or phases, that provides a 7. Maintenance 2. Requirements model for the development and lifecycle management of an application or 6. Deployment 3. Design software Typically, seven phases - 4. 5. Testing Implementation Requirement is part of the SDLC Software Development Life Cycle 1. Planning  Planning should clearly define the scope/boundaries and purpose of the application  It plots the course and provisions the team to effectively create the software  In the Planning phase, project management evaluates the terms of the project. This includes  calculating labor and material costs  creating a timetable with target goals - integrated master schedule  creating the project’s teams and leadership structure  Planning can also include feedback from  Stakeholders - customers, developers, subject matter experts, etc. https://phoenixnap.com/blog/software-development-life-cycle Software Development Life Cycle 2. Define Requirements Determine the functional requirements (services, behaviors)  For example, an autonomous navigation application would require the ability to detect and avoid obstacles Determine non-functional requirements (what are they?) Requirements also include defining the resources needed to build the project  For example, a team might develop navigation software to navigate a driverless car. The car, GPS, sensing devices, cameras, etc. are requirements in the process. https://phoenixnap.com/blog/software-development-life-cycle Software Development Life Cycle 3. Design The Design phase includes the software architecture that provides a structure of a system derived from the user requirements The design includes several aspects: user interface, platforms, programming, communications, security, etc. Prototyping can be a part of the design phase. - early version of the software can be made available for demo 4. Implementation Software development or coding, actual writing of the program Also includes unit testing, integration testing – finding and fixing errors https://phoenixnap.com/blog/software-development-life-cycle Software Development Life Cycle 5. Testing It’s critical to test an application before making it available to user The process of using the developed system with the intent to find errors.  Defects/flaws/errors found at this stage will be sent back to the developer for a fix and have to be re-tested.  This phase is iterative as long as the bugs are fixed to meet the requirements. Much of the testing can be automated. Other testing can only be done in a simulated production environment for complex deployments Testing should ensure that each function works correctly, and the overall application performs adequately wrt quality attribute https://phoenixnap.com/blog/software-development-life-cycle requirements (performance, availability, reliability, security, etc.) Software Development Life Cycle 6. Deployment In the deployment phase, the application is made available to users Deployment can be as simple as a payment portal and download link on the vendor website. It could also be downloading an application on a smartphone. Deployment can also be complex.  For example, upgrading a company-wide database to a newly- developed application. Because there are several other systems used by the database, integrating the upgrade can take more time and effort https://phoenixnap.com/blog/software-development-life-cycle Software Development Life Cycle 7. Operations and Maintenance At this point, the development cycle is almost finished. The application is done and being used in the field. In this phase, users discover defects/failures/errors that weren’t found during testing. These errors need to be resolved, which can spawn new development cycles. In addition to defect fixes, this phase undertakes development of new features, enhancements etc. Models like Agile development plan additional features in future releases. https://phoenixnap.com/blog/software-development-life-cycle  Various Life Cycle Models 15 There are many software process and life-cycle models, and, of these, many have a variety of permutations:  Code-and-Fix Model  Waterfall Model  V-Shaped  Spiral  Agile  Iterative  Scrum  Code-and-Fix Model This is the earliest method of “fixing” software and is really not a model at all Code and fix has two so-called phases, usually applied in an ad hoc manner  – The first phase is to write code  – The second phase is to fix it  What are the missing steps? To be discussed later.  Waterfall Model  Discussion: What is the Waterfall model?  Each discipline is deemed to be complete when all the appropriate work products for that discipline have been created and signed off  The requirements discipline considered to be complete  when all the requirements have been identified in detail and reviewed.  Then the outputs (e.g.. SRS) from requirements flows into the architecture discipline Classic Waterfall Model Phases Work Products Requirements SRS Design SAD Code & Unit Test.EXE Integration Prelim Build Test (Validation & Verification) Final Build Release Deployment d Product Hotfixes Maintenance Patches Minor Releases 18  V Shaped model  Defined by Paul Rook in 1980’s  Evolved from Waterfall Model but more emphasized on testing  Completion of each phase before next phase can begin  Process steps are bent upwards Wikipedia.com  Spiral Model  Developed by Boehm in 1986  Phases are defined cyclically ◦ The model is represented by a four-stage model through which the development process spirals 1. Objectives, constraints and alternatives are identified 2. Alternatives are evaluated, risks are identified and resolved 3. The next level of product is developed and verified 4. The next phases are planned  The basic differences between the spiral and the waterfall in addition to the four stages, is that the spiral is risk driven ◦ Risk processes can also be a problem area if approached without some experience  Iterative Process  Rational Unified Process (RUP) 2003 - the granddaddy of all the agile methods  Iteration: ◦ A short and set duration of a project ◦ Allow to demonstrate incremental value ◦ Obtain early and continuous feedback  A pass is made through each of disciplines ◦ Size of boxes = relative time spent performing activities/tasks within discipline  Each iteration results in ◦ Better understanding of requirements ◦ A more robust architecture ◦ A more experienced development org ◦ A more complete implementation  More productive and successful SW and Systems Process Engineering Meta-Model Specification (SPEM) Software and Systems Process Engineering Meta-Model Specification (SPEM) standard developed by Object Management Group (OMG), a nonprofit technology standards consortium.  SPEM standard is influenced by and supports several existing SW development methods (OpenUP- Unified Process, Rational Unified Process, IBM Unified Method Framework) An effective software development method should describe who does what, how, and when  Roles: The Who (BA)  Work products: The What (e.g., Defining Requirements)  Tasks: The How (e.g., Collect the stakeholder’s requests)  Phases, iterations, and activities: The When Key Method Concepts and Their Relationship Iterative Process  Phases – OpenUP defines four sequential phases: ◦ Inception Phase:  Where the business case and objectives for project is established  Where the focus is on requirement definitions ◦ Elaboration phase:  Where the architecture is established  Where the architect expends the most effort ◦ Construction Phase:  Where the remaining requirements are clarified  Where development of the system is completed on the baselined architecture ◦ Transition Phase:  Where the system is deployed in user’s environment for acceptance testing  Where project should be to close out by the end  Activity 25 Requirement Architecture Development Define Create Logical Create Logical Requirements Architecture Detailed Design Testing Create Physical Create Physical Architecture Detailed Design Defining the requirements – outline and detail functional requirements as well as non-functional requirements. Architects focus on the ASRs when deriving the architecture. Solution elements are selected to satisfy the stated requirements. Creating the Logical Architecture – moving from requirements to solution. Describe tasks that produce logical architecture Creating the Physical Architecture – maps logical to physical  Activity - Define Requirements 26 The iteration starts with the definition of the SW requirements in the Define Requirements activity. Tasks: Collect Stakeholder Requests : is to gather the requests that various stakeholder place on the system Capture Common Vocabulary : is to ensure that common business and technical terms used by stakeholders are understood and documented Task: Define System Context: is to ensure that the boundary of the system under development is understood and the users and external systems that interacts with the system are identified … Key Method Concepts and Their Relationship Inception Iter 1...Iter n Defining Elaboration Requirements Construction Transition Collect Stakeholder Requests Capture Common Vocabulary Define System Context Business analyst, Outline Functional Requirements Application/infrastructu ….. re architect, Stakeholder Software Requirements Spec Functional Reqs Non-Functional Reqs Change Requests Agile Process - Agile Manifesto  The Four Values of The Agile Manifesto (2009)  Agile Principles The Agile Manifesto is based on twelve principles: 1. Customer satisfaction by rapid delivery of useful software 2. Welcome changing requirements, even late in development 3. Working software is delivered frequently (weeks rather than months, sprint) 4. Close, daily cooperation between business people and developers 5. Projects are built around motivated individuals, who should be trusted 6. Face-to-face conversation is the best Even form late in of communication (co-location) developmen 7. Working software is the principal measure t of progress 8. Sustainable development, able to maintain a constant pace 9. Continuous attention to technical excellence and good design 10. Simplicity—the art of maximizing the amount of work not done—is essential 11. Self-organizing teams (Scrum team) Able to maintain 12. Regular adaptation to changing circumstances (Sprint retrospective) constant pace Scrum Technical team excellence Lesson-learned good design 29 https://leadagile.in/2017/11/26/12-agile-principles/ Understanding Agility  The first is when talking about agile approaches to software development: ◦ moving fast, embracing change, releasing often, getting feedback, etc.  The second use of the word relates to the agile mindset and how people work together in agile environments. ◦ This is usually about team dynamics, customer collaboration, and other things associated with creating high performing teams ◦ React: If a software team can’t deliver software and keep pace with changes in the environment, the team is not agile ◦ Adapt: If a large, slow-moving organization that rarely changes and takes months to deliver software, is it still be considered “agile” organization by their customer? 30 Agile Mindset  Defined by four agile values, guided by 12 agile principles, and manifested through many common practices based on needs Pair Programming Continuous integration ATDD Test Driven development User stories Feature-Driven development from the Agile Practice Guide, © PMI Agile Methodologies  There are over a dozen agile methodologies  No single right way  Can be tailored once a team is experienced  Most common ◦ Scrum ◦ Extreme Programming (XP)  Agile Process - Scrum  Scrum is one of the framework under the Agile software development ◦ Scrum emphasizes taking a short step of development, inspecting the resulting product Did it meet expectations? ◦ and the efficacy of current practices How can we work better or make the product better? ◦ and then adapting the product goals and process practices Is this still the most valuable feature to deliver at this time? ◦ Repeat forever!!!!!  Scrum focuses on: ◦ Content of an iteration (Sprint) ◦ Prioritized requirements to be considered in iteration (Sprint Backlog) ◦ A Short daily meeting (a Scrum meeting)  Scrum methodology will be discussed in more detail in the next lecture Design Coding Test Extreme Programming (XP) Characteristics ◦ Focuses on productivity and software quality ◦ Quick releases, with a recommended two-week iteration ◦ Each iteration results in production-ready code ◦ Highly productive, self-organized teams  XP Core Practices ◦ Small releases – smaller increments mean rapid deployments ◦ Pair programming/testing: two programmers- one enters code, the other ensures that code is accurate, periodically switch roles ◦ Test-driven Development (TDD) – writes acceptance tests prior to developing code ◦ Customer tests – customer describes test criteria ◦ Continuous integration – check code into a build several times a day ◦ Simple design – adapt as necessary/revisit as needed  The main difference between Scrum and XP is that XP contains many practices that are specifically for programming (TDD, continuous integration, and pair programming)  Summary 35  Software Life Cycle Processes  SDLC  Models  Code-and-Fix Model  Waterfall Model  V-Shaped  Spiral  Agile  Iterative  SPEM  Scrum  XP Just a few more slides, let’s take a short break! https://www.dreamstime.com/illustration/take-break.html Requirements Engineering CSPC 541 Fall 2024 Prof. Son Nguyen Class Exercise #2 (Extra credit)  Class Discussion #2: 5 -10 minutes Code and Fix Model: 1. What are the missing steps? 2. Although the Code and Fix Model has so many problems/issues, why is it still being used today.  The class is divided into teams to discuss and present their thoughts on this topic. ◦ Team 1 & 2: Q1 ◦ Team 3 & 4: Q2 ◦ Must be present in class and participate to get full points. ◦ No make-up Class Exercise #2 (Extra credit) 1. What are the missing steps?  Problems include lack of process steps that include ◦ Lack of analysis or requirements investigation ◦ Lack of trade off for cost or performance purposes ◦ Lack of architecture or design activities ◦ Lack of integration or testing phases Class Exercise #2 (Extra credit) 2. As discussed, although the Code and Fix Model has so many problems/issues, it is still being used today. Code and Fix model is still used today ◦ because it is simple and fastest to implement changes ◦ because of “schedule pressure". Code and Fix model can help developers to get the software released sooner to meet the deadline set by stakeholders. ◦ Used by organizations (startup, CMMI Level 0/1) that have limited resources and no established/defined software development process in place, ◦ Used it when doing R&D model, prototyping, or proof-of- concept experiments for a quick development turnaround. Requirement Engineering ◦ Requirement Engineering (Chapter 3)  Goals  Activities  Tools  Traits of good requirements  Artifacts produced  Requirements Engineering (RE) 42 Requirements engineering (RE) refers to the process of formulating, documenting and maintaining software requirements and to the subfield of Software Engineering concerned with this process. Nuseibeh B. and Easterbrook, S. Requirements Engineering: A Roadmap, ICSE 2000 Future of Software Eng. Goals of RE:  Combine known software requirements into single, coherent view or a single version of the Truth  Define as many software requirements as possible  Goal = “All”  Change happens!  Provide inputs to Architectural Design  Goals of Requirements Engineering (continued) 43  To meet these goals, we need to understand  The functions the product must perform  The data that will be used/created  The relationships between the data and the functions  The relationships between the data Example: Autonomous Navigation system Functions: navigation, steering, route selection, position and velocity sensing. Obstacle avoidance Data: position, speed, messages (Position Velocity Messages, Navigation Display Update, Routing Request Message) Relationships: [SN-0020] The system shall cease automatic steering upon receipt of a State Change Message indicating “Off”. [SN-001] The system shall update its current position and velocity upon receipt of valid Position Velocity Messages  Requirement Engineering Activities 44  The activities involved in RE vary widely, depending on the type of system being developed and the specific practices of the organization(s) involved.  These may include:  Requirements inception or requirements elicitation – collecting requirements of a system from users/stakeholders  Requirements identification - identifying new requirements  Requirements analysis and negotiation - checking requirements and resolving stakeholder conflicts  Requirement Definition - outlining and detailing functional requirements as well as non-functional requirements http://en.wikipedia.org/wiki/Requirements_engineering  Requirement Engineering Activities 45  Requirements specification - documenting the requirements in a requirements document (e.g., software requirements spec)  Requirements validation - checking that the documented requirements spec and models are consistent and meet stakeholder needs  Requirements verification - checking that the designed/built software meets the software requirements spec  Requirements management - managing changes to the requirements as the system is developed and put into use These are sometimes presented as chronological stages although, in practice, there is considerable interleaving of these activities. http://en.wikipedia.org/wiki/Requirements_engineering  Traits of Good Requirements 46 Clear, simple, unambiguous  Vague or “minimal” requirements cause Bad Things  Always work in customer’s favor. Why?  May never finish development  A clear & concise requirement …  must consist of a single requirement (“Shall” or “Must”)  should be no more than 30-50 words in length  must be easily read and understood by non-technical people  must be unambiguous and not susceptible to multiple interpretations  must not contain definitions, descriptions of its use, or reasons for its need  must avoid subjective or open-ended terms (e.g., all, any)  Traits of Good Requirements 47 Are these requirements clear and concise? 1. When the user accesses a screen, it shall display on the monitor within 2 seconds. 2. All screens shall appear on the monitor quickly. 3. The development of the support system shall include infrastructure and development of operating procedures, addition of logistics tools in the areas of maintenance management, configuration management, and technical publications, as well as the entire tool set for system software maintenance and development of new functionalities in the delivered products. Motherhood, vague!  Traits of Good Requirements 48 Is it Complete?  contains all the information that is needed to define the system function,  leaves no one guessing (For how long?, 50 % of what?)  includes measurement units (inches or centimeters?)  Examples: 1. The system shall cease automatic steering upon receipt of a State Change Message indicating “Off” 2. The system shall generate commands to the steering actuators and one or more Speed Change Requests to return the vehicle to its previous direction and speed upon receipt of an Obstacle Position Message. Incomplete indication … indicating that the obstacle is no longer a factor.  Traits of Good Requirements 49 Consistent  Requirements agree with each other  Examples: 1. The communication network provided on the CSU campus shall be TCP/IPv6 compliant. Note: An on-going training program for TCP/IPv6 network needs to be established at the Cal State Fullerton site. 2. The campus communication network shall be IPv6 RFC 791 compliant. Note: An on-going training program for IPv6 RFC 791 IP Internet Protocol needs to be established at the Cal State Fullerton site.  Do these refer to the IPv6 RFC or IPv4 RFC? RFC 791; (IP Internet Protocol) IPv4 RFC 2460; IPv6 Traits of Good Requirements (continued) 50 Implementable/ Free of Implementation Details  Given available time, resources, technology, etc.  Examples: 1. After 3 unsuccessful attempts to log on, the user shall be locked out of the system. 2. After 3 unsuccessful attempts to log on, a Java Script routine shall run and lock the user out of the system. Stated positively Avoid to use “shall not” or “must not” do something Traits of Good Requirements (continued) 51 Testable/Verifiable  Verification methods: Requirements can be verified by  Inspection  Demo  Test  Analysis  Examples: 1. The user interface shall be menu driven. It shall provide dialog boxes, help screens, radio buttons, dropdown list boxes, and spin buttons for user inputs. 2. The system shall be user friendly. Traits of Good Requirements - Examples 52 Is this requirement Viable or Feasible?  Examples: 1. The replacement control system shall be installed causing no more than 2 days of production disruption. 2. The replacement control system shall be installed with no disruption to production. Bad example- This is an unrealistic expectation. Traits of Good Requirements - Examples 53 Is this requirement necessary or needed?  A necessary requirement …  is one that must be present to meet system objectives  is absolutely critical for the operation of the system,  leads to a deficiency in the system if it is removed  Examples 1. The desktop PCs for the developers on the project shall be configured with quad core processor, 512 GB of memory, DVD, and dual 21-inch flat screen monitors. 2. All desktop PCs for the project shall be configured with quad core processor, 512 GB of memory, DVD, and dual 21-inch flat screen monitors. This may not be needed for all PCs for the project Also, avoid use the word “all” in the requirement as it may be open-ended and may not be able to verify.  CSU System Architecture Layers - Example 54 CSU System System A-level spec COMPUTER COMM MOBILE FACILITIES Sub Systems HARDWARE DESIGN ITEMS SOFTWARE DESIGN ITEMS Components/ Design Items B-level spec DP VPS HWCIs CSCIs SIs Configuration Items VTC AVS IntComm SatComm C1 C2 CSU1 CSU2 LMS TRN EDE UHF HF SW Eng Env SW Components C-level spec Mech Eng Tools Vehicles Generators System/E Eng Env Operations Support Config Mgmnt Training Management System Training Materials Management System CSCI = Computer Software Configuration Item HWCI = Hardware Configuration Item SI = Support Item Logistics Management System  Traits of Good Requirements (continued) 55 CSU System System COMPUTER COMM MOBILE FACILITIES Sub Systems Traceable HARDWARE DESIGN ITEMS SOFTWARE DESIGN ITEMS Components/ Design Items  Upward to origin (e.g., system DP VTC VPS AVS HWCIs CSCIs SIs Configuration Items requirements or A-level ) IntComm SatComm C1 C2 CSU1 CSU2 LMS TRN EDE UHF HF SW Eng Env Mech Eng Tools SW Components System/E Eng Env Examples: traceability matrix(“child Vehicles Generators  Operations Support Config Mgmnt Training Management System Training Materials Management System to parent”) Logistics Management System Verifica Product Test tion Verific Requir Allocati Procedure Test Procedure Metho ation ID SI Requirement ement on Component Out-links (System/Subsystem Specification) ID ID Description d Level SSS-9999 The System Training Group shall be equipped a student tracking system to provide student progress monitoring The training SI shall track student progress and training TRN:Training SI Test- System SI-500 plan TRUE TRN Mgmt System SITest 01 Training Group D FAT  Traits of Good Requirements (continued) 56 Traceable (cont.) CSU System System COMPUTER COMM MOBILE FACILITIES Sub Systems  Downward to design (design items, HARDWARE DESIGN ITEMS SOFTWARE DESIGN ITEMS Components/ Design Items components), implementation (integration, CSCIs SIs code/unit/test), and test (test id, test procedures, DP VPS HWCIs Configuration Items VTC AVS C1 C2 CSU1 CSU2 LMS TRN EDE verification steps) IntComm SatComm UHF HF SW Eng Env Mech Eng Tools SW Components Vehicles Generators System/E Eng Env Operations Support  Examples: traceability matrix (“parent-to- Config Mgmnt Training Management System Training Materials Management System children”) Logistics Management System Verifica Product Test tion Verific System/Subsystem Requir Allocati Procedure Test Procedure Metho ation ID Specification ement on Component In-links (SI Requirement) ID ID Description d Level SSS-9999 The System Training Group shall be equipped a student tracking system to provide student progress monitoring. SI - 500 The Training SI shall track student progress and training plan. System Test- TRN:Training SI - 599 The Training SI shall maintain an SSS Test- System Training TRUE TRN Mgmt System archive of student training history records. TRN1 Group D FAT  Artifacts Produced by RE 57 Requirements Document Operational Concept Trace Tables  Requirements Document 58 Defines requirements software must meet  Single definition of Truth Formal agreement with Customer  Modifiable only with approved Change Request Requirements include “shall” or “must”  Legal meaning  Are given unique identifiers (requirement id)  Are formally tested or verified Statements of intent include “will” or “should”  Behavior or trait software should exhibit to meet requirements  Not formally tested or verified Concept of Operations (ConOps) Document 59 A ConOps is a user-oriented document that describes system characteristics for a proposed system from the users' viewpoint. The ConOps document is used to communicate the overall quantitative and qualitative system characteristics to the user, buyer, developer and other organizational elements (e.g., training, facilities, staffing and maintenance). It is used to describe the user organization(s), mission(s) and organizational objectives from an integrated systems point of view. 132-1998 – IEEE Guide for Information Technology - System Definition - Concept of Operations (ConOps) Document Concept of Operations (ConOps) Document 60 Describes how customer/users intend to use product  Not how product works  Not requirements  Scenarios Provides guidance to engineering team  Insight into customer/user needs and expectations  Why requirements are the way they are Sets expectations for customer/users  Ensures consistency over time ConOps - example https://edisciplinas.usp.br/pluginfile.php/4136477/mod_resource/content/1/AP- R479-15_Concept_of_Operations_for_C-ITS_Core_Functions.pdf  Trace Tables 61 For each requirement, it shows:  Parent requirement(s)  Test Procedure ID, Description  Proposed test method  Demonstration (D)  Analysis (A)  Test (T)  Inspection (I)  Test Level or Test Event  Factory Acceptance Test (FAT)  SW Functional Qualification Test or Computer SW Configuration Item (CSCI)  Site Acceptance Test (SAT)  System Test CSU System Requirements/Architecture - Example 62 CSU System System A-level COMPUTER COMM MOBILE FACILITIES Sub Systems HARDWARE DESIGN ITEMS SOFTWARE DESIGN ITEMS Components/ Design Items DP HWCIs CSCIs SIs VPS B-level Configuration Items VTC AVS IntComm SatComm C1 C2 CSU1 CSU2 LMS TRN EDE UHF HF System requirements (A- SW Eng Env Mech Eng Tools SW Components Vehicles Generators spec) are flowed down to the System/E Eng Env Operations Support subsystems, CIs (B-spec). Config Mgmnt In order to sell off A-spec Training Management System requirements, all the B-spec Training Materials Management System requirements must be Logistics Management System successfully verified first  Trace Tables CSU System System 63 COMPUTER COMM MOBILE FACILITIES Sub Systems Requirement SI-100 shows: HARDWARE DESIGN ITEMS SOFTWARE DESIGN ITEMS Components/ Design Ite  Parent requirement: SSS-9999 DP VPS HWCIs CSCIs SIs Configuration Items VTC AVS  Test Procedure ID, Description IntComm SatComm C1 C2 CSU1 CSU2 LMS TRN EDE UHF HF Proposed test method SW Components  SW Eng Env Mech Eng Tools Vehicles Generators System/E Eng Env Operations Support Config Mgmnt  Demonstration (D) Training Management System Training Materials Management System Logistics Management System  Test Level – Test event  FAT (Factory Acceptance Test) Verifica Product Test tion Verific System/Subsystem Requir Allocati Procedure Test Procedure Metho ation SSI Specification ement on Component SSS Requirement (Parent) ID ID Description d Level SSS-9999 The System Training Group shall be The Training SI shall maintain equipped a student tracking system to an archive of student training TRN:Training provide progress monitoring. SI Test- System SI-100 history records. TRUE TRN Mgmt System SITest 01 Training Group D FAT  Summary 64  Goals of Requirements Engineering (RE)  RE Activities  Requirement inception  Requirements ana______  Requirements mana______  Requirements ver______and val________  Traits of good requirements  clear and conc…  Complete  Consistent  testable or ver______  Free of im________  Viable or feasible  Artifacts produced  Concept of o_______(CONOPS)  System/Software R______ S______(SRS)  T___ Tables  Coming Next…  Next week (Week 3), we will discuss:  Business Requirements  Agile/Scrum process  Project I assignment  Class project -  Class will be divided into 5 Scrum teams  5-6 students per team  Teams will be assigned randomly  Teams and project will be assigned in the class  Homework assignments ◦ Read Chapter 3, 4 ◦ Introduce yourself to your professor and classmate (5 points)  Due today at 5 PM  Make sure to include a photo of yourself on your post  Reply to at least one or more classmates 65