logging in or signing up Software requirements Demian Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: Embed: Flash iPad Dynamic Copy Does not support media & animations Automatically changes to Flash or non-Flash embed WordPress Embed Customize Embed URL: Copy Thumbnail: Copy The presentation is successfully added In Your Favorites. Views: 14979 Category: Education License: All Rights Reserved Like it (8) Dislike it (2) Added: August 01, 2007 This Presentation is Public Favorites: 1 Presentation Description 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) Comments Posting comment... By: sac27 (48 month(s) ago) plz allow downloading this slides I require them for studying Saving..... Post Reply Close By: Demian (48 month(s) ago) Hi, you may download it now. Saving..... Edit Comment Close By: Demian (77 month(s) ago) Importance of SRS in testing lifecycle. Saving..... Post Reply Close Saving..... Edit Comment Close Premium member Presentation Transcript TCSS 360, Spring 2005Lecture Notes : 1 TCSS 360, Spring 2005Lecture Notes Requirements Analysis Relevant Reading: Software Requirements: A TutorialStuart Faulk Software requirements : 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) Requirements abstraction : 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." Software lifecycle, review : 4 Software lifecycle, review The software lifecycle (Faulk's view): requirements -> system testing -> deployment -> maintenance | ^ | | +- preliminary design -> integration testing | ^ | | +- detailed design -> unit testing | ^ | | +- coding ----------+ Requirement roles to people : 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 Requirement definition, spec. : 6 Requirement definition, spec. A sample requirement : 7 A sample requirement requirement documents do not have a unified format, but generally the reqs are numbered and listed categorically, like this: Requirement doc examples : 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 Classifying requirements : 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? Functional requirements : 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. Non-functional requirements : 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. Non-functional requirements : 12 Non-functional requirements Requirements example : 13 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. Requirements example behavioral: use Java, 5 sec transaction, encryption dev. quality attributes: adaptable to other machines Some requirement measures : 14 Some requirement measures Essential difficulties : 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 Accidental difficulties : 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 Faulk's requirements approach : 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 Problem analysis, basic issues : 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 Semantic/packaging properties : 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 "State of the practice" : 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. Functional decomposition : 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 Example functional decomp. : 22 Example functional decomp. A functional decomposition requirement might look like this: Structured analysis : 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 Sample data flow diagram : 24 Sample data flow diagram Data flow diagram syntax : 25 Data flow diagram syntax Account # & deposit balance query User account database account data Get deposit Create account summary Check deposit Printer Input Output Processing element Data type Direction of data flow Data store …... Operational specification : 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! Object-oriented analysis : 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 Software cost reduction : 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 Trends and emerging tech. : 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 Requirements exercise : 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. You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.