Software Engineering and project management

Software Engineering and project management compressed notes for unit 2 (System requirement)

1. Unit -2
Software Requirements

2. Functional and non-functional requirements, user requirements,
system requirements, interface specification,
The software requirements document
Requirements engineering process: Feasibility studies , requirements
elicitation and analysis, requirements validation, requirements
management
Software project effort and cost estimation –Cocomomodel I, Cocomo
Model II, LOC, Function point metrics

3. Functional and non-functional requirements
•Software system requirements are often classified as functional requirements or
nonfunctional requirements:
1. Functional requirements These are statements of services the system should
provide, how the system should react to particular inputs, and how the system
should behave in particular situations. In some cases, the functional requirements
may also explicitly state what the system should not do.
2. Non-functional requirements These are constraints on the services or functions
offered by the system. They include timing constraints, constraints on the
development process, and constraints imposed by standards. Non-functional
requirements often apply to the system as a whole, rather than individual system
features or services.

4. Readers of Different types of requirements
specification

5. Functional Requirements

6. Non-Functional Requirements

8. Non-Functional classifications

9. Goals and Requirements

10. Metrics for specifying non functional requirements

11. Domain Requirements

12. The software requirements document
(Software Requirements Specification-SRS)

13. Agile methods and requirements

14. Users of a requirements documents

15. The structure of a requirements document

17. Requirements Engineering Process

18. Feasibility Study
The objective behind the feasibility study is to create the reasons
for developing the software that is acceptable to users, flexible to
change and conformable to established standards.
•TypesofFeasibility:
1.TechnicalFeasibility-Technicalfeasibilityevaluatesthe
currenttechnologies,whichareneededtoaccomplish
customerrequirementswithinthetimeandbudget.
2.OperationalFeasibility-Operationalfeasibilityassesses
therangeinwhichtherequiredsoftwareperformsaseries
oflevelstosolvebusinessproblemsandcustomer
requirements.
3.EconomicFeasibility-Economicfeasibilitydecides
whetherthenecessarysoftwarecangeneratefinancialprofits
foranorganization.

19. A spiral view of requirements engineering
process

20. Requirements elicitation and analysis

21. Problems of requirements analysis

22. The requirements elicitation and analysis process –4 stages

24. Requirements validation

25. Requirements checking

26. Requirements validation techniques
1. Requirements reviews The requirements are analyzed systematically by a team
of reviewers who check for errors and inconsistencies.
2. Prototyping In this approach to validation, an executable model of the system in
question is demonstrated to end-users and customers. They can experiment with
this model to see if it meets their real needs.
3. Test-case generation Requirements should be testable. If the tests for the
requirements are devised as part of the validation process, this often reveals
requirements problems. If a test is difficult or impossible to design, this usually
means that the requirements will be difficult to implement and should be
reconsidered. Developing tests from the user requirements before any code is
written is an integral part of extreme programming.

27. Requirements management

28. Changing Requirements

31. Requirements management planning

32. Requirements change management

33. Requirements change management

34. Software project-Effort and cost estimation
•Software cost and effort estimation will never be an exact science. Too many
variables— human, technical, environmental, political—can affect the
ultimate cost of software and effort applied to develop it
•To achieve reliable cost and effort estimates, a number of options arise:
1.Delay estimation until late in the project (obviously, we can achieve 100%
accurate estimates after the project is complete! -is not practically possible).
2. Base estimates on similar projects that have already been completed.
3. Use relatively simple decomposition techniques to generate project cost and
effort estimates.
4. Use one or more empirical models for software cost and effort estimation.

35. •Decomposition techniques take a "divide and conquer“ approach to
software project estimation. By decomposing a project into major
functions and related software engineering activities, cost and effort
estimation can be performed in a stepwise fashion.
•Empirical estimation models can be used to complement decomposition
techniques and offer a potentially valuable estimation approach in their
own right. A model is based on experience (historical data) and takes the
form

36. Empirical Estimation Models

37. The COCOMO Model ( COnstructive COst MOdel )
•Barry Boehm introduced a hierarchy of software estimation models bearing the
name COCOMO, for COnstructive COst MOdel. The original COCOMO model
became one of the most widely used and discussed software cost estimation
models in the industry. It has evolved into a more comprehensive estimation
model, called COCOMO II.
•Like its predecessor, COCOMO II is actually a hierarchy of estimation models that
address the following areas:

38. COCOMO 1 Model:
•The Constructive Cost Model was first developed by Barry W.
Boehm.
•The model is for estimating effort, cost, and schedule for
software projects.
•It is also called as Basic COCOMO.
•This model is used to give an approximate estimate of the
various parameters of the project.
•Example of projects based on this model is business system,
payroll management system and inventory management
systems.

39. COCOMO –II Model

40. COCOMO –II Model

41. Complexity weighting for object types

42. Productivity rate for object points

45. Lines of Code (LOC) & Function Point
(FP)
1. Lines of Code (LOC) :
Theline of code(LOC) metric is any line of text in a code that is
not a comment or blank line, in any case of the number of
statements or fragments of statements on the line. LOC consists
of all lines containing program header files, declaration of any
variable, and executable and non-executable statements. As
Lines of Code (LOC) only counts the proportion of code, you can
only utilize it to compare or estimate projects that utilize the
same language and are programmed using the same coding
standards.

46. Example of Line of Code :

47. Function Point (FP)
•Function Point (FP) :
In thefunction pointmetric, the number and type of functions
held up by the software are used to find FPC (function point
count).