INFO 637Lecture #51 Software Engineering Process II Defining Requirements INFO 637 Glenn Booker

INFO 637Lecture #52 What are Requirements? Requirements describe key characteristics and capabilities desired for your product Requirements include functions your product can perform (functional requirements), and every other aspect of your product or how it was created (non-functional requirements)

INFO 637Lecture #53 Requirements Scope Requirements can cover not only your product (which may include software, hardware, and networking components) but also:  Documentation  Training  The process for creating the product  Service or maintenance

INFO 637Lecture #54 FURPS+ One way of describing requirements is using the FURPS+ breakdown  F is for Functional  U is for Usability  R is for Reliability  P is for Performance  S is for Supportability  The “+” is for everything else (Stolen from Larman’s Applying UML and Patterns, 2 nd ed.)

INFO 637Lecture #55 Functional Requirements Functional Requirements include every method of obtaining input, processing inputs, and generating outputs Often this is the most complex list of requirements Directly relates to system-level testing after product is completed – can each requirement be met?

INFO 637Lecture #56 Usability Requirements Usability requirements describe how your product was designed to accommodate interaction with humans Includes human factors, types of help available, and documentation Some non-functional requirements may be testable, others not

INFO 637Lecture #57 Reliability Requirements Reliability requirements may specify goals for mean time between failures (MTBF), recoverability, and predictability of results  Particularly used for mission-critical systems

INFO 637Lecture #58 Performance Requirements Performance relates here to how fast or how much the product can accomplish These typically include response time for queries, volume of throughput, and/or resource usage (e.g. in terms of CPU, disk, memory, or network traffic)

INFO 637Lecture #59 Supportability Requirements How easy is it to support this system? How easy is it to adapt to new needs, or be reconfigured? How easy is it to maintain? Can it adapt to other countries (e.g. language, power needs, etc.)?

INFO 637Lecture #510 Other Requirements The “+” includes other kinds of requirements:  Implementation constraints (hardware, resources, etc.)  Interfaces to external systems (which you don’t control)  Operations; how is it used operationally?  Packaging; how is it shipped?  Legal; export and licensing issues

INFO 637Lecture #511 Constraints Requirements can include constraints on your product or how it is created  Comply with existing PC’s, or development environment, or database system  Comply with business rules  Comply with physical or logistical constraints  Must be developed by a woman-owned, CMM level three small business (for example!)  Or any other kind of constraint

INFO 637Lecture #512 Software Requirements Spec Requirements can be captured in a Software Requirements Specification (SRS) The SRS can also be used as a contract, binding the developer to commit to exactly what they will create for the customer  Helps avoid misunderstandings and unhappy customers by making expectations clearer

INFO 637Lecture #513 Communication is the Key While a good SRS is very helpful, the bigger need is for the developers and customer to communicate with each other  Driving 100 mph in the wrong direction won’t get you to your destination and faster!  Similarly, starting development without knowing what you need to create won’t help you finish quickly

INFO 637Lecture #514 Requirements Change Even projects with “well known requirements” from the beginning typically have 30% of those requirements change before the project is completed Must expect requirements will change, and create a process to control those changes

INFO 637Lecture #515 Requirements Change Changes cost time and effort – need to quantify those to know how much cost to expect  Otherwise it’s like taking your car to a mechanic and telling them to do whatever they want Often a Configuration Control Board (CCB) is used to determine whether a particular change is acceptable

INFO 637Lecture #516 Change Control To determine if a change is needed, follow some sort of process  See Change Control handout First step is to screen or scrub the proposed change  Do we understand what is suggested?  Is it really needed?  Has someone already suggested it?

INFO 637Lecture #517 Change Control Then we need to estimate how much work the change will be  Estimate size, cost, and effort needed to implement it  Determine who could best implement it  Determine its priority Then start implementing the change after approval by the CCB

INFO 637Lecture #518 Change Control The developers create the change, do unit testing, and get peer review approval of the change Once ready, the CCB may determine when the change will be implemented (often the next available build) Many changes may be built together, and tested to make sure they all work

INFO 637Lecture #519 Change Control Then the CCB reviews the system test results, and approves release of the change The change is now part of the new system baseline Process is very similar for software system maintenance, not just development

INFO 637Lecture #520 Extracting Requirements Requirements are obtained (elicited) by working from the most clearly understood aspects to the most vague  Assess system feasibility  Understand organizational issues  Identify system stakeholders  Record requirements sources

INFO 637Lecture #521 Extracting Requirements  Define operating environment  Assess business issues  Define domain constraints  Record requirements rationale  Prototype poorly understood requirements  Define usage scenarios  Define operational processes

INFO 637Lecture #522 Another Example The sample RFI includes examples of functional requirements, constraints, and meaningless jabber  See Sample SIR handout Can you tell them apart?

INFO 637Lecture #523 SRS Structure Many different structures are available for an SRS  The text’s is on page 113  An SRS may range from a few pages long to hundreds The SRS may be used to write system- level test procedures, to test whether every requirement works in the final product

INFO 637Lecture #524 SRS Script The development script for creating the SRS includes:  Reviewing and clarifying the system needs  Allocating parts of the SRS to be done by each team member  Developing the system test plan  Inspecting the SRS and test plan  Refining the SRS and test plan

INFO 637Lecture #525 End Product This phase results in a completed (baselined) SRS and the system test plan  While simple in concept, these control everything which happens from this point on They are now baselined documents, so changes to them need to be submitted via the change process (form CCR)