Lecture on Requirements Analysis

1. Lecture on Requirements Analysis www.AssignmentPoint.Com www.assignmentpoint.com

2. Software requirements • requirements: specify what to build • tell "what" and not "how" • tell the system design, not the software design • tell the problem, not the solution (in detail) • What are some goals of doing requirements? • understand precisely what is required of the software • communicate this understanding precisely to all development parties • control production to ensure that system meets specs (including changes)

3. Requirements abstraction "If a company wishes to let a contract for a large software development project, it must define its needs in a sufficiently abstract way that a solution is not pre-defined. The requirements must be written so that several contractors can bid for the contract, offering, perhaps, different ways of meeting the client organization's needs. Once a contract has been awarded, the contractor must write a system definition for the client in more detail so that the client understands and can validate what the software will do. Both of these documents may be called the requirements document for the system."

4. Software lifecycle, review • The software lifecycle (Faulk's view): requirements -> system testing -> deployment -> maintenance | ^ | | +- preliminary design -> integration testing | ^ | | +- detailed design -> unit testing | ^ | | +- coding ----------+

5. Requirement roles to people • roles of requirements • customers: show what should be delivered; contractual base • managers: a scheduling / progess indicator • designers: provide a spec to design • coders: list a range of acceptable implementations / output • QA / testers: provide a basis for testing, validation, and verification

6. Requirement definition, spec.

7. A sample requirement • requirement documents do not have a unified format, but generally the reqs are numbered and listed categorically, like this:

8. Requirement doc examples • Let's look at some SRS documents that we can scrape from the web. It's easy to find them on Google by searching for things like:requirements document filetype:doc

9. Classifying requirements • Faulk doesn't like the normal way to classify requirements, which is the following: • functional: map inputs to outputs • nonfunctional: other constraints • performance, dependability, reusability, safety • How does Faulk prefer to classify them? • behavioral: everything about implementation • features, performance, security • can be objectively observed / measured • development quality attributes: things about internal construction • flexibility, maintainability, reusability • subjective, relative; who says what design is more maintainable?

10. Functional requirements • Examples of functional requirements: • The user shall be able to search either all of the initial set of databases or select a subset from it. • The system shall provide appropriate viewers for the user to read documents in the document store. • Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

11. Non-functional requirements • Examples of non-functional requirements: • It shall be possible for all necessary communication between the APSE and the user to be expressed in the standard ASCII character set. • The system development process and deliverable documents shall conform to the process and deliverables defined in XYZCo-SP-STAN-95. • The system shall not disclose any personal information about customers apart from their name and reference number to the operators of the system.

12. Non-functional requirements

13. Requirements example • What are some behavioral and development quality requirements in the following text? • We will implement our bank teller ATM software in Java. It should handle cash withdrawals and deposits in under 5 seconds wait time. It should be done in such a way that we can adapt it to our other types of ATMs and machines for our bank. We will use encrypted network connections to avoid hackers spying on users' account information. • behavioral: use Java, 5 sec transaction, encryption • dev. quality attributes: adaptable to other machines

14. Property Measure Speed Processed transactions/second User/Event response time Screen refresh time Size K Bytes Number of RAM chips Ease of use Training time Number of help frames Reliability Mean time to failure Probability of unavailability Rate of failure occurrence Availability Robustness Time to restart after failure Percentage of events causing failure Probability of data corruption on failure Portability Percentage of target dependent statements Number of target systems Some requirement measures

15. Essential difficulties • What does "essential" difficulty mean? • What are some of the essential difficulties? • comprehension: people don't know what they want • communication: hard to specify clearly what is wanted • control: can't see which requirements will dominate schedule • inseparable concerns: can't divide up problem, or freeze from change • must compromise on divide-and-conquer, and make tough trade-offs • something that is hard about reqs, by nature

16. Accidental difficulties • What does "accidental" difficulty mean? • What are some of the accidental difficulties? • written as an afterthought: devs write requirements after coding, instead of at beginning • confused in purpose: has too much marketing info, too imprecise (to let the customer change it later), or has too much design/implementation info in it • not designed to be useful: no time or thought put in; makes requirements poor and useless • lacks essential properties: incomplete • something made difficult by writing reqs poorly

17. Faulk's requirements approach • requirements approach defines: • process: activities, entrance/exit criteria, people to do work • products: the tangible products to produce, and their details • requirements phase • problem analysis: describe the problem situation • requirements specification: create SRS(Software Requirements Specification) document

18. Problem analysis, basic issues • This phase describes the problem that must be solved by the software we will produce • elicit requirements from customer • how might this be done? • decompose problem into pieces • organize info, communicate to involved parties • resolve conflicting needs • what is an example of some conflicting needs? • know when to stop

19. Semantic/packaging properties • Faulk says that a well-written SRS document should have the following semantic properties (qualities of its content): • complete, precise, unambiguous, consistent • implementation-independent • verifiable: it can be shown whether or not a given implementation meets spec • Faulk also recommends pleasant packaging: • modifiable, readable, ready for reference/review

20. "State of the practice" • Faulk notes several trends in requirements that have been used over the years: • functional decomposition • structured analysis • operational specification • object-oriented analysis • software cost reduction • Let's discuss each of these in detail.

21. Functional decomposition • What is functional decomposition? • What are some advantages and disadvantages of functional decomposition? • specifying what the software is supposed to do • mapping from inputs to outputs • proceeding top-down, dividing each function into subfunctions + close to the code; developers like it - forces design/code decisions too early; inflexible

22. Example functional decomp. • A functional decomposition requirement might look like this:

23. Structured analysis • What is structured analysis? • What are some advantages and disadvantages of structural analysis? • address accidental difficulties with a model of problems, and procedures for what to do • shifts to focus on the data being processed and the transformations made on that data (from MIS) • common artifact: data flow diagram (DFDs) + systematic, not ad-hoc - hard to know where to divide data / transform; DFD is more about design

24. Sample data flow diagram

25. Data flow diagram syntax Get deposit Input Processing element User Account # & deposit Output Direction of data flow Printer Data type Check deposit …... balance query Create account summary account data account database Data store

26. Operational specification • What is an operational specification? • What are some advantages and disadvantages of operational specifications? • a prototype; executable requirements written in some sort of formal language • a layer of abstraction to allow design decisions later + requirements lead directly to executable result - does not always work, in practice; sometimes can't distinguish from programming the actual product!

27. Object-oriented analysis • What is object-oriented analysis? • What are some advantages and disadvantages of object-oriented analysis? • decomposing the problem into a set of interacting objects and classes • focuses on abstraction, decomposition, and real-world entities + more closely related to modern prog. languages - can't represent everything as an object; tailors to a certain language; doesn't always lead to an SRS

28. Software cost reduction • What is software cost reduction? • What are some advantages and disadvantages of software cost reduction? • used by Navy for aircraft flight system • S. Faulk worked on this; continues involvement with ongoing SCR work • Faulk now teaches at U. of Oregon Software Engineering program + saving money is good - not well-documented; only used to rewrite existing code; done only by researchers, not programmers

29. Trends and emerging tech. • domain specificity • most engineering disciplines have subdomains with different methodologies for each • practical formalisms • formal methods, slow to be adopted by industry • improved tool support • CASE: computer-aided system engineering • since SW Engr. is immature, tools haven't been able to be standard and specific (note: this hasn't changed much!) • integrated paradigms • the different requirement styles are becoming more similar over time (evolutionary) • government tools use formal semantics

30. Requirements exercise • Let's sketch out some requirements for a bank ATM software program. This is the software that appears on the screen of the ATM and walks you through deposits and withdrawals.With a partner, come up with 4 requirements for such software, that you think are important. Try to be specific. Write them down and classify each as functional/non-functional or behavioral/development quality, to the best of your ability. Then we'll discuss them together.