Software Requirements By Pete SawyerSoftware RequirementsSlide 3Why is it important?Requirements and ConstraintsSlide 6Slide 7Slide 8Requirements Engineering ProcessWhat are the activities?Slide 11Slide 12Slide 13Slide 14Requirements ElicitationSlide 16Slide 17Requirements SourcesSlide 19Slide 20Slide 21Slide 22Elicitation TechniquesSlide 24Slide 25Slide 26Requirements AnalysisSlide 28Slide 29The System BoundarySlide 31Slide 32Requirements ModelingSlide 34Why derive more requirements?Derived requirementsSlide 37Slide 38Requirements AttributesSlide 40Requirement Trade-offsSlide 42Software Requirements SpecificationSoftware Requirements SpecificationSlide 45Requirements ValidationRequirements ValidationSlide 48Slide 49Slide 50Slide 51Requirement ManagementSlide 53Change ControlSlide 55Slide 56Version ControlSlide 58Requirements TracingSlide 60Slide 61Status TrackingQuestions?Software RequirementsBy Pete SawyerPresented by Ehsan GhaneieEEL6883 – Software Engineering IISoftware RequirementsSoftware requirements concern the specification of software systemsSoftware systems are always derived from some business problem They are always embedded in an operational contextThey have interfaces to human users, business process elements, or other hardware/software systemsSoftware RequirementsDerivation of software requirements can rarely be isolated from underlying business problemSoftware requirements are not a discrete area of software engineeringThey are part of the system engineering process known as requirements engineeringWhy is it important?An effective RE process that minimizes occurrences of requirement errors is critical to success of any development projectThe cost of rectifying errors in the requirements increases significantly as development proceedsRequirements and ConstraintsA Requirement defines a property or capability that the system must exhibit in order for it to solve the business problem for which it was conceived Functional Requirements describe a function that the system must perform Nonfunctional (Extra-Functional) Requirements describe the qualities of a systemHow well the system operates within its environmentThe quality of delivery of functional requirementsSome requirements are emergent properties and dependant on a wide range of factors some of which are hard to analyze and control Satisfying such requirements depends upon how the whole system operates within its environment, and not just a particular system componentRequirements and ConstraintsRequirements are specified at several points on a spectrum that ranges from those with a business focus to those with a technical focusAt the highest level are the goals of a system that set out in very broad strategic terms what is needed to solve some business problem Identifying these needs usually motivates a development projectRequirements and ConstraintsThe next level of requirements define what must be observable in a black-box system that solves the business problemThese are called user requirements Stakeholder requirementsSystem requirementsThe technically focused requirements exist only to make it possible to satisfy the business focused ones Constraints are like negative requirements and act to limit the set of possible solutionsSoftware RequirementsRequirements Engineering ProcessRequirements ElicitationRequirements SourcesElicitation TechniquesRequirements AnalysisThe System BoundaryRequirements ModelingDerived RequirementsRequirements AttributesRequirement Trade-offsSoftware Requirements SpecificationRequirements ValidationRequirements ManagementChange ControlVersion ControlRequirements TracingStatus TrackingRequirements Engineering ProcessIs a process that must transform a business problem into a specification of the properties of a system that will provide an appropriate solution to the problem, through a set of activitiesWhat are the activities?The properties that the system must exhibit must be elicited Elicited requirements must be subjected to analysis to establish a set of requirements that are correct, complete, and feasible This set of requirements must be then recorded in a specification document that communicate the requirements to the people who will use them to develop the softwareRequirements Engineering ProcessThe documented requirements must be then validated to ensure the software they specify will meet the needs of the people whom from the requirements were elicited As development proceeds requirements need to be managed so that changed are controlledRequirements Engineering ProcessThis process begins with scoping the system which involves understanding the underlying problem that the system is to address, identifying the goals of the system, and outlining how it will operate in its environmentThen the system requirements are elicited from their sources, analyzed, and validatedFor each software component, further analysis of the allocated requirements is used to derive the requirements that fully specify the softwareRequirements Engineering ProcessIt is not always possible to capture all the requirements If the product’s environment is volatile, the requirements will also be volatile When software products are developed to compete in the market, the requirements are likely to evolve with the market Other factors such as meeting the release dates can also affect the RE processSoftware RequirementsRequirements Engineering ProcessRequirements ElicitationRequirements SourcesElicitation TechniquesRequirements AnalysisThe System BoundaryRequirements ModelingDerived RequirementsRequirements AttributesRequirement Trade-offsSoftware Requirements SpecificationRequirements ValidationRequirements ManagementChange ControlVersion ControlRequirements TracingStatus TrackingRequirements ElicitationRequirements elicitation is the process of discovering the requirementsThe requirements engineer must identify the sources of requirements, collect information about the problem from these sources, and synthesize requirements from this informationRequirements ElicitationRequirements elicitation is not a passive learning process about what stakeholders want Instead, the requirements engineer must dig beneath the stakeholders’ accounts for their concerns, needs, and desires to