Requirements Activities

1. Requirements Activities Business Analysis Requirements Design Code-Implementation code prototype Test Case Design Testing Builds Rel.

2. Significance of Requirements • A Key Ingredient in “specifying” the Project • Software Success/Failure Profile by CHAOS Rept. -1994) • Key causes for many project failures • Top 3 reasons for project failure: • Lack of user involvement • Incomplete Requirements & Specifications • Changing Requirements and Specifications • Key causes for many project successes • Top 3 reasons for project success • User Involvement • Executive Management Support • Clear Statements of Requirements

3. Key Problems Facing Requirements Engineers • Many managers “strongly” want to get to coding as fast as possible • Lack of cooperation from users and customers. • Elicitation (are right people available to talk to) • Verification (are right people available to review) • Inability and, possibly desire, of the business analysts to perform the requirements engineering tasks Hopefully, this course helps

4. 2-sides of Requirements Requirements Developers Users/ Customers Requirements must be described in such a way that multiple and different audiences can understand and use it.

5. System Requirements • Defines what the system is to do --- its functionality • Defines the circumstances under which the system is to operate --- its constraints • Usability • Performance and Reliability • Quality • Security • Interfaces • Data representations • Business Flow We need to understand the users and their environment before we can define many of the above. ---- So, requirements engineers have to be 1) business and people oriented as well as 2) technically oriented.

6. Different ‘types’ of Requirement Statements • The system is to keep track of all the patient appointments by doctors, time slot, and date. It should also trigger a telephone reminder 1 day prior to the appointment date. ---- general • The system will allow clinic personnel to check any patient appointment by name or by time. --- specific functional feature • The system must run on MS-Windows system --- specific system(implementation) running environment / interface • The system will only allow authorized personnel to have access to the system --- security • The system must respond to any query request within one second --- specific system performance • The system must be able to handle up to 50 simultaneous users at the same time --- specificsystem performance What does this include ? --- functionalities, business flow, data ? May need to dig deeper on “authorized”

7. What are Requirements? • Requirements are statementsthat describe the needs and wants of the users/customers. • 6 major categories of requirements: • business flow and parts that need automation or improvement, along with: • User profiles • User operational flow profile • functions and features that the system is to provide • interfaces (looks and navigations) • data • existing systems and interfaces • operational constraints • performance • reliability • security Note that “wants” may not be “needs”

8. The “What’ .vs. “How” Debate • Some say - Requirements should only state “what” a system should perform, but not “how” the system should perform those tasks. • This is too simplistic a view. In fact, in order to describe all • the needs and wants of the users/customers, there often • will be statements that touches on how the “solution” needs • to be implements. • a specific data basebecause the users already have it • a certain looks to the UI to match existing systems • a specific code interface to an existing system • etc.

9. What is Requirements Engineering? • Requirements engineering is a set of activities related to establishment of “agreed to” or “accepted” requirements: • Discovering and soliciting (elicit) requirements • Validating (Reviewing) the requirements • Analyzing the requirements (priority, consistency, etc.) • Documenting/Specifying the requirements • Maintaining the requirements • Manage the requirements Do notconfuse this with SALES ! The set of activities is “engineering” because it is - systematic and - repeatable (Not there yet, but we have made a lot of progress towards systematic and repeatable)

10. Requirements Engineering Process • Requirements engineering process is a structured (sequenced) steps of the requirements engineering activities - - - • Note that: Organizations may not have a well defined process but still engage in some of the requirements engineering activities • * Also Note that : we do not talk about “planning” as a step in the requirements engineering activities (what needs to be planned?)

11. Ideal Requirements Engineering Process • There is NO one ideal requirements engineering process. • There is a US government standard that mentions a process: • US DOD standard 2167A • MIL-STD-498 • IEEE std 830 (specification guide) • Each individual organization must create a process that fits the needs of the organization and the type of projects.

12. Cost of Requirements Engineering Sidebar: Requirements activities related to a global enterprise may cost as much as $1million ----- before you get the project, just for bidding the project! • The cost of requirements engineering is dependent on the type and the size of thesoftware “problem” (note ---not the size of software product, which is the solution) • How do we estimate requirements engineering cost (time, effort, resources)? There is no fixed answer - - it depends on circumstances- - - For large and complex problems, requirements engineering may cost 15%-20% of the overall software effort. Smaller ones may still cost 10% of the overall effort. A side note: COCOMO estimation recommends adding 8% more to the project effort estimate for requirements

13. Consequences of Wrong Requirements • Requirements is a key factor for both success and failures of software projects. If they are erroneous or incomplete: • Software system may be delivered late or cancelled • Customers may not be able to use the software system and cancel the order or use it with degrees of dissatisfaction • The cost of fixing and maintaining the system may be high and be a source of discontent for both the customers and the support personnel A major cause of Project Failure (Chaos Rept)

14. No Ideal Requirements Engineering Process • There is no one ideal process • May vary by size and type of project • Often not very well defined • So ---- the emphasis has also focused on the “output” of requirements engineering Gather Analyze Specify Req. Spec. Manage These activities are never smooth and has lots of “re-dos”

15. Requirements Specification Document • A document which states all the requirements (users’ needs and wants - or – users’ problems). • It is often called the Software Requirements Specifications (SRS) Document This document is used by multiple parties (stakeholders): - so it must cater to - different needs - “ to - different level of knowledge - “ to - different interests etc.

16. Who are the Stakeholders of a Software Project ? • A stakeholder of software project is a - person or - organization who will be affected by the software project. • Stakeholders for software requirements are all the people who will be affected by the requirements: • Users and customers • Designers, developers and testers • Trainers • Marketing and sales personnel • Support and maintenance personnel • Project Management and administrators ( *** including lawyers) Project mgmt uses requirement statements for cost/effort estimation – often off by 200%! Lawyers use req. statements for project contracts.

17. Requirements Document Content • Requirements document is a document that describes the users or customers needs and wants in a form of a system description. It should contain: • Services and functions that this system should provide • Constraints under which this system must operate • Non-functional properties (emergent properties) of the system such as performance, security, etc. • Other systems that this system interfaces • Information about the application domain and user business • Constraint on development schedule, cost, etc. Page 15 of your text: For product Use earlier slide on What are Requirements - - - note the 6 types of information that need to be considered

18. IEEE/ANSI 830-1993 • Requirements document structure • Introduction • 1.1 Purpose of requirements document • 1.2 Scope of the product • 1.3 Definitions, acronyms and abbreviations • 1.4 References • 1.5 Overview of the remainder of the document • 2.General description • 2.1 Product perspective • 2.2 Product functions • 2.3 User characteristics • 2.4 General constraints • 2.5 Assumptions and dependencies • 3. Specific requirements • Covering detailed functional, non-functional and interface requirements. • 4. Appendices • 5. Index The meat of the document are chapters 2 & 3

19. Requirements Representation • Mostly written in “natural” language; thus there are plenty problems: • Confusion • Incompleteness • Inconsistency • Non-preciseness • But “natural” language also has the most expressive power • There are graphical languages that can help in representing requirements: e.g. • UML’s Use Case Diagram • UML’s Activity Diagram

20. Try Designing a Requirements Representation Form • How would you relate the different types of requirements in Section 3 of IEEE format requirements document? Functionality Business flow Systems & Interfaces Data & Formats User Interfaces • Non-Functional Constraints: • - performance • reliability • security • etc.

21. Relationship between Requirements and Design • These are inter-related: • Requirement specifications generally feed into design activity • However - - - there may be constraints that will force reiteration of the requirements: • Regulated “standards” already set for the system design • Reuse of existing design for cost and schedule reasons • Requirements may be only for a component of existing system and thus may have to be altered to fit the whole • Existing systems interface may dictate some changes to requirements

22. Relationship of Requirements and Testing • Requirement statements represent what the customer/user expects in the final product delivered to them • How do we know what we deliver as a final product is what the requirements stated? • We have to validate the final product against the requirements (demonstrate to both customers and ourselves) • Test-case design starts as soon as requirements are understood and specified

23. Requirements Management • Requirements management is a set of planning and controlling activities to ensure that: • Qualified resources are available for the various requirements activities • An agreed upon set of activities are carried out: • Requirements solicitation and gathering is performed • Requirements prototype, if necessary, is built and analyzed • Requirements are prioritized and specified/documented • Requirement specifications are reviewed and approved • Requirements specification baseline is established and change control is put in place for subsequent changes to requirements. Note that: Some define requirements management as“managing” the relationship among different requirements ---- e.g. traceability relationship

24. Systems Engineering • Most systems include both hardware and software. So requirements often have to be broader and include both. • The systems we “build” may be: • Configuring and Integrating existing components (your laptop) • Custom built to a user specification (We are more concerned with these) • There are 3 Broad Classes of Systems • Information systems (most of the business systems) • Embedded systems (software acts as controller) • Command and Control systems (real time, military system, weather modeling, mathematical model of financial mkt, etc.)

25. Systems Engineering Process • Look at page 14 of your text - - - (next slide) discuss in class - - - 1) is it clear enough to follow ? 2) is it detailed enough for you know what to do ?

26. Figure 1.2 of Text: System Engineering Process System Validation Systems Req. Engr. System Integration Architectural Design Requirements Partitioning Sub-system(s) Development Software Req. Engr.

27. multiple-sides of Requirements Requirements Doc. Developers Users/ Customers Support Marketing Trainers . . . . 1. Requirements are read more often than they are written, making it a worthwhile investment. 2. Readers of the requirements document come from various backgrounds. 3. Writing clearly and concisely is HARD; make sure it is 1) given to qualified personnel, 2) allotted enough time, and 3) reviewed.