Feasibility Study

Feasibility Study and Requirements Engineering
Institut fr Softwaretechnologie
3. Feasibility Study and Requirements Engineering

Topics: t Preparation of a software development project t Determination of the requirements of software product (requirements engineering) t Estimation methods for product size and development costs t Construction of project plans Attention: Thorough treatment of topics - like project planning and cost estimation are beyond the scope of this course. In this course these topics are only roughly overviewed.
Prof. S. Noureddine, UoL
82
3.1 Feasibility Assessment of a Software Project

Like in every other product development a software development project should also begin with a feasibillity study that considers: the technical feasibility the economical feasibility the personal feasibility of the project using different realization alternatives (risk estimation!). In this respect, it is to be differentiated between software products for: concrete customer: in genral the software product is needed, it is "only" to clarify what the customer wants exactly. anonymous market: trend studies, market analyses, etc. are to be undertaken in order to clarify how useful and how rentable the product is.
2 83
Constituents of the Feasibility Study: t Requirements document (1st version): roughly lists all technical requirements of the software from the customer's point of view (traditionally, it is not determined how these requirements are to be realized). t Project calculation: the size of the desired software product is estimated and the development costs are derived therefrom. t Project plan: time schedule for the accomplishment of the project with the decomposition into phases and determination of results of each phase and of responsibilities. Main Problems: t how is the size of a software product dened? t how can one estimate the product size without considering a specific realization? t how are product size, development time, and development costs interrelated?
84
Determining Requirements: t Needs = review of existing business processes, problem descriptions: why should software be developed? t Features = document with rough description of the main functions of the new software: what functions are to be realized? t Software Requirements = Document with detailed description of the tasks of the software: still "what" functionality is considered and not how the desired functionality is to be realized. Needs
Features
Software Requirements
85
Number and Effect of Errors in Requirements:

20.0 (Maintenance) C osts of Error Corrections Errors removed in phase X can originate from phase X or be an aftereffect of errors in earlier phases.
5.0 (Acceptance test)
Conclusion:
2.0 (Module test) 1.0 (Coding) 0.5 (Design) 0.1 (Analysis) Project runtime (Phases) Relative error # 1.00 1.25 1.75 1.00 5.00 Almost a third of all analysis errors remain undiscovered until delivery. To remove these errors during maintenance (instead of during analysis) is 200 times more expensive .
Origin of error Analysis Design Coding Other Total
Elimination rate 77% 85% 95% 85% 85%
Delivered error 0.23 0.19 0.09 0.24 0.75
86
3.2 Construction and Properties of the Requirements Document

A requirements document of a software product can be constructed as follows: 1. Project goal: what goals should be achieved by the software product. 2. Product deployment: application domains and targeted groups are determined. 3. Product functions: main functions are described from the user's point of view (no auxiliary functions) and they are numbered (e.g. LF nn). 4. Product data: permanently stored Hmain data are determined and numbered (e.g. LD nn). 5. Product performance: particular requirements of main functions or main data (execution time, amount of data , ) are specified (LL nn). 6. Quality requirements: general properties like high reliability, excellent usability, acceptable efciency, are determined. 7. Supplements: any important thing that does not match any of the above.
87
Other Properties of the Requirement Document: t Addressees: customer and contractor (project leader, ) t Form: concise structure and sentences in natural language t Content: fundamental properties of the product from client's point of view t Time/Date: before contracting (potentially used for contract, too) t Size: few pages Functions, data, and performance categories: The importance of all functions, data, and performance (requirements), which are mentioned in the requirements documents, should be stated. A typical classification is as follows: t absolutely important (high priority, primary, ) t fairly important (medium priority, secondary, ) t knickknack (low priority, optional, frill, )
88
Further typical Attributes for Requirements: t Status: reflects the "state" of a stated requirement (e.g. suggested, agreed on, realized, ) t Benefit: expected benefit of a requirement, which is often equated with the priority (e.g. critical, important, useful, ) t Effort: estimated effort for the realization of a requirement (e.g. high, medium, low, ) t Risk: estimation of the likelihood that during the realization of a requirement (un)expected, undesired problems occur, which compromise the project. t Stability: estimation of the likelihood that a requirement will change during the project runtime (e.g. high, medium, low, ) t Release: Determination of the release (product generation) in which the requirement is to be realized. t Reason: Pointer to a source, which justifies why the requirement has been stated and what real benefit is connected to its realization.
89
Example Customer description of a software product: Motor Vehicle Reservation System (MVRS) A rental ofce lends motor vehicles of different types. The assortment comprises cars, vans, and trucks. Vans are small trucks, which may be used with the same driving license as cars. Some client may reserve motor vehicles of a certain category for a certain period. He or she has to sign a reservation contract. The rental ofce guarantees that a motor vehicle of the desired category will be available for the requested period. The client may cancel the reservation at any time. When the client fetches the motor vehicle he or she has to sign a rental contract and optionally an associated insurance contract. Within the reserved period, at latest at its end, the client returns the motor vehicle and pays the bill.
90
Problems with the Customer Description: t it does not include any statement concerning why the customer wants to support the outlined business process by software (e.g. because reservations have been already very often forgotten, maintenance intervals have been exceeded, ) t it includes undened terms, which can be interpreted differently by the customer and the software developer(s) (e.g. assortment, category, ) t it possibly includes irrelevant statements (e.g. "Vans are small trucks, which may be used with the same driving licence as cars") t it is still very incomplete (e.g. it is unclear what happens if the vehicle is not returned timely, if vehicles are not picked up after reservation, ) t it is unclear which parts of the described business process are to be realized in software (determination of the system boundary absent) t it includes only statements belonging to the functional activities of the considered business process (no statements about amounts of data, response time, kind of the users, )
Prof. S. Noureddine, UoL 91
Classical Example for Ambiguity of Statements: Examine the sentence "Mary had a little lamb" by emphasizing individual words and looking up the words in a dictionary (glossary): t have: 1) to hold in possession as property 2) to trick or fool someone (been had by a partner) 3) to beget or bear (have a baby) 4) to partake (have as dinner) 5) t lamb: 1) a young sheep less than one year without permanent teeth 2) the young of various other animals (antelope etc.) 3) a person as gentle or weak as a lamb 4) a person easily cheated or deceived 5) the esh of lamb used as food 6)
92
Possible Meanings of "Mary had a little lamb": have 1 2 3 4 lamb 1 4 2 5 Meaning Mary owned a little sheep under one year Mary tricked a person easily cheated Mary gave birth to an antelope Mary ate a little of the lamb
Consequences for the Collection of Requirements: t Find out all probably important (meaningful) words in an informal requirement definiton in natural language t Create a glossary of all important and/or possibly unclear terms that completes the requirements document (and later requirements analysis document) t More information about techniques for more precise (semi-formal) description of requirements using UML (Section 3.3)
93
Back to Requirements Document of the Software Product: 1. Goal: The program MVRS should enable a small car rental company with precisely one office to manage the accounting and rental of its different vehicle types (categories). 2. Product deployment: The product will be used in the office of the company by the owner of the company and by frequently changed temporary employees. 3. Product functions: /LF10/ first entry, change and deletion of vehicles. /LF20/ first entry, of vehicle types. /LF30/ first entry, of vehicle reservations. /LF40/ Ouput of available vehicles of a certain type within a specified time interval with the following data . /LF50/
4. Product data: /LD10/ Following data are to be stored for each vehicle: Type, Color, Mileage, last inspection, . /LD20/ Following data are to be stored for each vehicle reservation: Time interval, desired type (already reserved vehicle), Address of the customer /LD30/ 5. Product performance: /LL10/ In the output of functions /LF40/, only the first n vehicles are output. Further output only if desired. /LL20/ The should enforces a periodic data backup for the data /LD20/, . /LL30/ At most 100 vehicles and reservations are stored. /LF30/ The processing of a vehicle reservation should not last more than 10 seconds.
95
6. Quality requirements: Product quality Functionality Reliability Usability Efciency Modifiability Portability very good x x x x x x x good normal irrelevant
The usability of the functions /LF10/ and /LF20/ must be good, because they are only used by the owner of the company. The usability of all other functions must be very good, because they are used by changing temporary employees. 7. Supplements: The assignment of available vehicles to reservations is done manually in the first version, bookkeeping functions are not part of the software.
3.3 Methods for Determining Requirements

We already mentioned repeatedly that determining (all?) requirements of a software product is not easy. However, in the preceding section we did not explain how can one compile a requirements document based on the information of the custmomer , which include all important requirements of the product (complete). In literature, the following techniques (a.o.) are proposed for determining requirements (requirements elicitation): t Determining all interested groups (stakeholders) for the software product and making interviews with these interested parties t Use of workshops with a brainstorming process and/or storyboard techniques, where all interested groups should be represented t Determining requirements cases (typical functional processes) and potentially playing these cases through with distributed roles t
97
Stakeholders - Groups interested in the software product: The software product to be developed affects different person groups in general differently. These interested groups have often very different (potentially contradictory) interests. In our case only: t the owner of the car rental company t the temporary employees t the customers of the company t persons responsible for later maintenance It is the first task of the requirements elicitation to identify all involved stakeholders. When conflicts arise between the different stakeholder groups, it is the task of the software developer to "arbitrate" (moderate)
98
Interviews with the customer (stakeholders): Using interviews (questions should be prepared previously) or potentially also using questionnaires one tries to get answers for e.g. the following items: t Prole of the customer (task, products, success, ) t Problems of the customer (what are the inefcient processes, error-prone, how have been the described problems solved before, how in future) t Environment of the customer (e.g. what kind of users, what kind of hardware) t expected properties fo the software product (functions, reliability, support, installation, ) t
99
Brainstorming Workshop for Determining Requirements: All person groups affected by the software product (including customer and software developers) are called together to a workshop that lasts one or two days. The workshop has the following phases: t material for preparation/agreement is sent in advance t first ideas (for requirements = functions) are gathered ideas on a slip of paper stapled e.g. on a wall criticism to expressed ideas is prohibited wild ideas explicitly desired amendment, combinations of ideas is desired t after that, ideas are grouped and irrelevant ones eliminated and in this way the desired functions of the software product are determined t finally, the investigated functions are sorted using priorities (potentially voting is needed here between the stakeholders)
100
Storyboard Techniques, Use Cases, and Role Games: The underlying idea for all of these techniques is that the most important functional processes of the software product are played through (provocation of yes, but ) t Storyboarding: had been used in the movie industry the first time for the production of "Snow witches and the seven dwarfs" use cases are played through on a big board (with roughly sketched user interface) (e.g. "vehicle reservation") t Use Cases: all functions (features) of the systems are described as exemplary processes main concept of UML for requirements analysis (see chapter 5) t Role Games: different persons take roles of different parts of the software system or users and play through different processes.
3.4 Writing Readable Documents

The following rules are valid for all documents that are wirtten in natural language. They are particularly valid for requirements documents! t no errors in writing: Spelling mistakes and grammatical mistakes are a sign of a disrespect of the reader and of a lack of reliability. in other words: the project is dead, if the requirements document contains many mistakes. t balanced structure: Depth of contents (at most 3 levels) and the length of the individual section should not vary (too much). t meaningful typography: r not too much different
fonts
and Sizes
r emphasize only tiltes and key terms r do not combine many emphasizing possibilities
102
t no adjectives: A well-organized structure is an integral part of a good design. should be replaced by A good design is well-structured. t yes for verbs: The implementation of the data structure has been done in form of an abstract data type. should be replaced by The data structure has been implemented as an abstract data type. t avoid redundancies and filler words: The class A is here a subclass of B, therefore, it inherits all attributes of B. should be replaced by A is a subclass of B.
t short sentences, no complex ones: As a precondition for the function it is to assure that all input arguments, thereby it is to be considered that the last argument, namely the checking mode, is optional if false is used, are to be a part of in the specified values range. should be replaced by As a precondition, all arguments must be in the specified values range. The checking mode is the last argument and it may be not used. If not used, the checking mode is switched off. or by (enumeraions are more clear) - Precondition: All arguments are within the specified values range. - Exception: The checking mode (last argument) may be not used. - Default: If not used, the checking mode is switched off.
104
t Well-advised use of English terms: In other languages (French, ...).
t But better English terms than wrong translations: Schnrkel rckplatz lscht die letzte Rolle vor dem Schnrkel. (German) (real fragment of an instruction manual!) Cursor backspace deletes the last character before the cursor.
105
How to use these rules? t read it loudly for yourself (please not in an office hall) t delete filler words, adjectives, mark unclear passages t check the logical construction t reconsider all marked places t use other persons for proofreading t again reconsider the places, which did not please proofreaders t use a "Spelling Checker" (automatic correction :-) t again read it loudly ,
106
3.5 Estimation of Efforts and Costs

The costs of a software product and the development time are determined mainly by the personal effort. The latter can be derived from: the size of the software product the required quality of the product Typical measure for personal effort: Man-months (MM) or man-years (MY): 1 MY 10 MM (because of vacation, sickness, ) Typical measure for product size: Lines of Code (LOC) = Number of lines of the implementation without comments Determination of the product quality: see
Section 1.4 and Chapter 7
107
Software size = Lines of Code? U sing the Lines of Code as a basis for project planning (and for measuring the productivity of developers) is questionable, because: code size is known only at the end of the implementation phas even the architecture on the subsystem level is unknown reusability with less LOC numbers is penalized thorough analysis, design, test, leads to lower productivity number of code lines depends on personal style of programming writing manuals, not well considered Attention: The strong dependency of LOC numbers on a certain programming laguage is ok, since the choice of a programming language has a big influence on the productivity.
109
Software size = Function Points! The Function-Point method for cost estimation uses the product requirements of the requirements document to estimate the product size. Each requirement is assigned one of 5 categories: 1. Input data (using keyboard, CD, external interfaces, ) 2. Output data (on monitor, paper, external interfaces, ) 3. Querie (e.g. SQL queries on an internal database) 4. Data files (internally changing database contens) 5. Reference files (mainly data that do not change) Then, it is counted, evaluated, .
110
Relation between Code size Function Points: Language Complexity Assembler C Fortran COBOL C++ Smalltalk 200 60 75 65 30 15 AVG = Lines of Code / Function Points low 320 128 107 107 53 21 medium 450 170 160 150 125 40 high
e.g. productivity in Smalltalk 4 times higher than in C
111
Overview of Estimation Methods: t Analogy method: Expert compares new project with already completed similar projects and estimates the costs based on his/her feeling Expert knowledge is not easy to present/understand t Percentage method: The distribution of efforts along the phases is determined from similar projects. Based on completed phases the remaining runtime of the project is estimated works at least after the analysis phase t Parkinsons law: Work is done, if the whole supply is used up. practice-oriented, realistic and less helpful t Weighting method: Determination of many factors (experience of developers, used languages, ) and combination by a mathematical formula LOC-based representative: COnstructive COst MOdel (COCOMO) FP-based representative: Function-Point methods in many variants
Institut fr Softwaretechnologiedeter
Determining FP Effort Curve: t In the first project one has to use known curves (for similar projects): e.g. IBM curve, VW AG curve, ) t The ratio of MM to FP in finished projects is used to "calibrate" the curve: new value pair is inserted new value pair replaces an older one Quality of the FP method: t the LOC-based method has been propagated for a long time t now: FP method is the only halfway functioning estimation method t deviations are huge (in particular, when foreign curves are used) t adaptation to OO models and modern user interfaces necessary t convenient only for input/output intensive systems (not for e.g. embedded systems)
Simple Rules of Thumb: Percentage method of Hewlett-Packard: r Analysis phase: 18% of whole effort r Design phase: 19% of whole effort r Coding: 34% of whole effort r Test: 29% of whole effort Continuous estimation of project advancement: Completion degree = effort done/ (effort done + rest effort) Rest effort is to be estimated in each iteration Completion degree may decrease correctness of the estimation increases with time
117
Determining of the optimal development time (after Jones): with small communication overhead and high degree of parallelism: Time = 2,5 * (Effort in MM)
s = 0,38 for batch systems s = 0,35 for online systems s = 0,32 for realtime systems
average Team size = Effort / Time Consider above formula: communication and management effort increase more than proportionally with increasing number of developers maximum number of developers working in parallel is proportional to product size and varies with the project runtime number of developers working in parallel in a project: developer (Putnam curve):
time
118
3.6 Project Plans and Project Organization

At the end of the feasibility study a project plan is to be constructed: Identication of individual work packages Time schedule (when packets are due?) Resource planning (assignment of persons to packages, ) Here it becomes very obvious that a feasibility study without a rough design of the software is not feasible, because: work packages result from the structure of the software dependencies and size of packages as well way of realization of packages are determined by resources Consequence: Project planning and project organization is a continous process. At project start only a preliminary plan is feasible, which is refined during project runtime.
119
Decomposition of the Project in Work Packages: MVRS MVRS

3. Coding (Module test) 4. Integration (System test)
1. Analyse Analysis
2. Design Design
5. Do cu. Doku
3.4 List construction
3.1 Database schema
5.1Manual Manual
3.5 User Interface
3.2 Query Operations
5.2 OnlineHelp
3.3 UpdateOperations
There is no information about the person-weeks in the abouve figure.

Planning of dependencies between work packages (PERT charts):

5.17.02 Listconstruction 5.31.02 Query operations 4.12.02 Analysis 4.26.02 Design Design 5.03.02 Database schema 6.14.02 Integration (System test) 6.28.02 Delivery Abnahme
5.31.02 Update operations
5.03.02 User interface
5.31.02 Online Help
Manual Manual 4.26.02
Work plan for the first generation of the product (without planning of feedbacks that arise if a completed activity is repeated).
Gantt chart:
4.12.02 1. Analysis 2. Design 3.1DB Schema 3.2 DB Updates 3.3 DB Queries 3.4 Lists 3.5 User interface 5.1 Manual 5.2 Online Help 4. Integration (System test) 6. Delivery 4.26.02 5.3.02 5.17.02 5.31.02 6.14.02 7.09.02 7.12.02
Time for a package:
Net time:
Buffer time (oat):
122
Gantt chart with personal planning:

4.12.02 4.26.02 5.3.02 5.17.02 5.31.02 6.14.02 7.09.02 7.12.02
John
(reponsible for all phases)
Design Analysis
DB Schema
Lists
DB Updates Integration
Bill
Manual
Online Help
Delivery
Sam
Vacation
User Interface
DB Queries
Test
Net time: Buffer time: (oat)
Attention: After resource assignment new time restriction may occur: e.g. lists after DB schema
123
3.7 A Final Check List

A feasibility study should last only few days (in general). Potentially, a before-project is reasonable, in which technical risks, etc. are studied. The following issues must be clear: t is the information in the requirements document agreed on by the relevant parties on customer side (attention when interests conflict on customer side)? t Is the product feasible using the planned resources? t Is there an acceptable cost estimation? t Is the product development economically interesting (or politically necessary)? t Is there a (realistic) time schedule with dates (deadlines) for all phase transitions (deadlines for individual activities may be absent)? t Is there a person responsible for each phase (assignment of resources to individual activities may be absent)? t Has risk assessment been done (absence of group members, )?
124

Feasibility Study

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Feasibility Study

Uploaded by

Copyright:

Available Formats

Feasibility Study and Requirements Engineering

3. Feasibility Study and Requirements Engineering

Prof. S. Noureddine, UoL