CSE4002 SE Studio Project Sita Ramakrishnan
Requirements Engineering, Value-based Engineering and IEEE SRS
Class Discussions to revolve around:
? Working towards the Functional Specification Document and the Legal Document to be
signed off by the client
? Deed to be signed by each member of the student team
? Project Management (see notes on Project Mgmt, PMBOK, reference: Project Management – rdPlanning and Control Techniques by Rory Burke, 3 Ed. John Wiley)
? Contrast some of the Traditional Planning and Control techniques used in Software
Engineering against the Value-based Software Engineering
? Business case, Stakeholders, Client’s input
? Requirements Engineering – Processes and Techniques (G Kotonya and I Sommerville, John
o Define what various terms in the Requirements Domain mean
o Process and techniques associated with Requirements elicitation, requirement
engineering, requirement management
? ANSI/IEEE Standard 830-1998 for Software Requirements Specification from
http://www.lib.monash.edu.au/databases/i.html from IEEE Explore and Standards and 830
Also refer SRS Templates from
o Process involved in developing system requirements
Requirements Document is a.k.a Functional Specification & a.k.a. System Requirement Specification
(SRS). The Requirements Document describes:
o The functionality and services the system should provide
o Constraints under which the system must operate
o Other systems which the system must integrate with
IEEE has defined standards for requirements documents. IEEE/ANSI 830-1998 suggests a structure for
requirements document. Monash Staff & Students can access this document at
www.lib.monash.edu.au/databases/i.html and visiting IEEE Explore -> Standards ->830 or directly from
Systems Engineering is concerned with system development as a whole and includes hardware,
software and operational processes. Systems Engineering Process Activities include:
System Requirement engineering -> Architectural design -> Requirements into subsystems (may have
hardware & software requirements) -> Software requirements engineering -> h/w & s/w subsystem
development -> system integration -> System validation.
Some hints and guidelines for writing requirements:
o Define standard templates for describing requirements - to reduce the likelihood of important
information being missed, and for ease of reading
o Consistent language usage – be concise, precise, use tables, lists, bullets where appropriate.
o Use diagrams where appropriate – modeling
CSE4002 SE Studio Project Sita Ramakrishnan
Value-based Software Engineering
Researchers in the Economics-Driven Software Engineering Research (EDSER – see
http://www.grabpage.org/~edser/) claim that
? Software Engineering Practice and Research is conducted predominantly in a value-
? Decisions in SE are guided by technical considerations and are not clearly aligned to
maximizing the net payoffs of project costs/investments .
? We must recognise that the ultimate arbiter of success in a software project is the net
value added to the organisation
? EDSER’s aim is to advance the theory and practice of software engineering by
viewing them as value-seeking activities – concept of ―value‖ is drawn from
theoretical insights and advances from finance, strategy, decision theory, game
theory, politics, etc.
In our SE practice Unit and other Projects undertaken, and as stated in Boehm and Huang’s article
titled ―Value-based Software Engineering: A Case Study‖ (Computer, IEEE, March 2003, p.33—41),
we have tended to:
? Treat all the requirements, use case, defects etc as equally important.
? Use modeling tools to express the design and transform them into implementation.
? Use earned –value systems to track project cost and schedule (look at our discussion
on Project management and PMBOK), but not concern ourselves with stakeholder
or business value.
? See S.E ers role as turning requirements into working implementation.
? Improvements are seen from a technical perspective alone and not from the
stakeholder (business) perspective.
Since software is all pervasive in today’s world, and software decision has implications for system cost,
schedule, and value, it is no longer feasible to adopt a value-neutral paradigm. Such a paradigm cannot
deal with most software project failures. Boehm states that some of the reasons for project failures are:
? Lack of user input.
? Incomplete or imprecise or changing requirements.
? Unclear objectives, unrealistic expectations and unrealistic timeframes.
A Value-based Software Engineering approach includes the following aspects:
(see article referred to above and also, Boehm (2003), Value-based Software Engineering, ACM
Software Engineering Notes)
? Requirements Engineering – developing a requirements document taking into
account, the needs (value props) of various stakeholders (anyone affected in some
way by the ―new‖ system) and reconciling these value props into a acceptable set of
objectives for the system.
? System Architecture – reconcile system objectives with various architectural
? Design and development – with value aspect included
? V & V – to operate as an investment activity
? Planning and control – planning and control to include value delivered to the
stakeholder as well , apart from the traditional view of cost, schedule and milestone.
? Risk Management – identify, analyse, prioritize and mitigate risk.
? Quality Management – rank quality factors w.r.t stakeholder’s value props.
? People Management – include ethical aspects as well as standard mgmt practices.
? Principles and practice – these include COT based systems, agile methods, RAD,
high dependability systems and ethics according to Boehm.