Software Require Specification

Slide 1: 

Requirement Engineering Asad Ur Rehman Chief Technology Officer Feditec Enterprise Presentation is based on Pressman 5th Edition RE roadmap” by Nuseibeh & Easterbrook

Slide 2: 

Background FediteC We build system like the Wright brothers built airplanes. Build the whole thing, push it off the cliff, let it crash, and start over again. Don’t you think in every real sense, we develop our software in same fashion? Surprises (most of them) are not discovered until the software was built and pushed off a cliff. If the software crashed due to incorrect function, inappropriate behavior, or poor performance, we picked up the pieces and started over again.

Slide 3: 

FediteC You must have noticed that in reality, software cannot function in isolation from the system in which it is surrounded, and hence requirements engineering has to include a systems level view. It means Requirement Engineering is a branch of systems engineering, whose ultimate goal is to deliver some systems behaviour to its stakeholders. Background

Slide 4: 

FediteC When any organization works in manual environment, giving them just software will not solve their problem, going for computerization requires more than that. They used to perform their routine work manually but computerization will change the way they used to work. It is complete change of culture. Staffs need to understand the software functionality, information linkage, and the built-in control. If change is not managed properly, it could be counter productive and the purpose of computerization will fail. Background

Slide 5: 

Requirement Engineering - Definition FediteC What’s Requirement? [IEEE Std] A condition or capability needed by a user to solve a problem or achieve an objective. The set of all requirements forms the basis for subsequent development of the system or system component. What is Requirement Engg? [Zave94] Requirements Engineering is the branch of systems engineering concerned with real-world goals for, services provided by, and constraints on software systems. Requirements Engineering is also concerned with the relationship of these factors to precise specifications of system behavior and to their evolution over time and across system families.

Slide 6: 

Requirement Engineering FediteC Requirement Engineering provide the appropriate mechanism for understanding what the customer wants, analyzed need, assessing feasibility, negotiating a reasonable solutions, specifying unambiguously, validating requirements. It can be divided into following areas; 1- Requirement Elicitation 2- Requirement Analysis and Modeling 3- Software Requirement Specification 4- Requirement Validation 5- Requirement Management

Slide 7: 

Requirement Engineering FediteC It provide the basis for; Analyzing requirements Validating that they are indeed what stakeholders want Defining what designers have to build, and Verifying that they have done so correctly upon delivery It highlights the importance of real-world goals that motivate the development of a software. These represent the why as well as what of a software.

Slide 8: 

Issues in Requirement Engg FediteC How to get from (informal) requirements to (formal) specifications ? How to check that specifications meet requirements ? How to deal with requirements we can't formalize ? How to reason about non-functional requirements such as security, maintainability, and reliability ? How to deal with changing requirements ? How does formality help with traceability ?

Slide 9: 

1- Requirement Elicitation FediteC The term elicitation is preferred to capture, to avoid the suggestion that requirements are out there to be collected simply by asking the right questions. One of the most important goals of elicitation is to find out what problem needs to be solved, and hence identify system boundaries. These boundaries define, at a high level, where the final delivered system will fit into the current operational environment.

Slide 10: 

Requirement Elicitation FediteC Requirement Types Functional requirements Non-functional requirements Regulatory Requirements

Slide 11: 

Requirement Elicitation FediteC Requirement Gathering Techniques Interviews Document Analysis Requirement Workshop Prototyping

Slide 12: 

FediteC 2- Requirement Analysis & Modeling Requirement analysis is the first technical analysis step in the software engineering process. It is at this point that a general statement of the software requirement is refined into a concrete specification that becomes the foundation (baseline) for all the software engineering activities. Requirement analysis task is process of refinement, modeling, and specification derivation. The software requirement is modeled using a combination of graphical notation (DFD, ERD) and textual language.

Slide 13: 

FediteC Requirement Analysis & Modeling The information domain of the problem must be represented and understood. Models that depicts system data, function and behaviour, should be developed. The models (and the problem) must be partitioned in a manner that uncovers details in a layered (or hierarchical) manner. The analysis process should move from the essential description information toward implementation detail. The analysis task is guided by the following fundamental principles:

Slide 14: 

FediteC Requirement Analysis & Modeling Requirement analysis is software engineering task that bridges the gap between system level software allocation and software design, as shown in graphically. The software requirement specification (SRS) is developed as an outcome of the analysis. A review of SRS is yet another more detailed and refined method of analysis. Review is essential to ensure that the developer and the customer have the same perception of the system.

Slide 15: 

FediteC 3- SW Requirement Specification The objective of the software requirement specification is to refine the scope of the software requirements and produce an operational software component that can be properly integrated with other component of the system.  Software requirements analysis is a System Analyst task that bridges the gap between system level software specification and software design. The result of software requirements analysis is the creation of requirements speciation. Regardless of the specification mode, software requirements must be represented in a manner that leads to successful software implementation.

Slide 16: 

FediteC SW Requirement Specification The speciation should separate functionality from implementation. The desired behavior of the system should encompass data and the functional response to the system to environmental stimuli. A cognitive model rather than design or implementation model should be developed. The specification should describe the system as perceived by the users. The specification should be developed so that it is amendable to change. Specification information should be nested increasing levels of detail.

Slide 17: 

FediteC 4- Requirement Validation Requirement validation examines that specification to ensure that all system requirements have been stated unambiguously; that inconsistencies, omissions, and errors have been detected and corrected. Validation is the process of establishing that the requirements and models elicited provide an accurate account of stakeholder requirements. Explicitly describing the requirements is a necessary precondition not only for validating requirements, but also for resolving conflicts between stakeholders.

Slide 18: 

FediteC 5- Requirement Management Requirements prioritization and evaluation Requirements Change Management Requirements Tractability Requirement Management is a set of activities that help the project team to identify, control and track requirements and changes to requirements at any time as the project proceeds.

Slide 19: 

Requirements prioritization & evaluation FediteC To avoid misunderstanding of the release contents between customers and users on the one hand and the system and software developers on the other, requirements should be prioritized or ranked in some fashion. Possible Ranking could critical (must have), important (non-critical), or desirable (good to have). Each identified requirement statement should be unambiguous, verifiable and complete.

Slide 20: 

Requirements Change Management FediteC Submitting requirements change request Initially evaluating requirements change request Reviewing batches of requirements change request Schedule changes to documents, codes and test Implementing the scheduled changes Procedure for managing changing requirements needs to include following activities:

Slide 21: 

Requirements Traceability FediteC Requirement tracing means providing explicit information that identifies all the lower level requirements that drive from a higher level of requirement, and all the design or code elements that implement each specific requirements. To implement requirement traceability every requirement at each level must be clearly identified and tagged. The tags must of course be unique. The requirement tags supplied in the highest level of requirements documents don’t play a role in the development process until a lower level requirements or design document is written.

Slide 22: 

Traceability Matrix FediteC

Slide 23: 

Thanks FediteC