Wawasan Open University: TSE302/05 Software Requirements Assignment

This assignment delves into the intricacies of software requirements and specifications, offering a comprehensive analysis of the subject matter. The assignment begins by elaborating on three requirement levels: user, business, and product, using the Open Bravo e-commerce platform as a case study. It examines user requirements in terms of functionality, business rules, and quality attributes. The business level explores parameters to define problems and opportunities. The product level details functional and non-functional requirements. The assignment then addresses volatility issues in software requirements, outlining approaches to resolve them, including customer involvement, scaling adjustments, and external alterations. The student also illustrates specifications in terms of state, behavior, and state change using sample scenarios. Finally, the assignment covers risk dimensions in software development, categorizing risks into three groups and elaborating on each dimension.

Running head: SOFTWARE REQUIREMENTS AND SPECIFICATIONS
SOFTWARE REQUIREMENTS AND SPECIFICATIONS
Name of the student:
Name of the University:
Author Note:

1SOFTWARE REQUIREMENTS AND SPECIFICATIONS
Assignment 1
In relevance to a software project, elaborate the 3 requirement levels in
terms of:
A. User level
The user level for the concerned case study of Open Bravo for implementing the innovative e-
commerce based operations includes 3 contrasting portions:
 Requirements for the users.
 Rules associated with the business.
 Quality attributes.
From the perspective point of view of the users, the requirements of the users is directly
proportional to the functionality of the software item. The user based requirements elaborates the
functions needed to be executed by the software for the accomplishment of the desired objectives.
Even for the purpose of achievement of the desired business requirements, multilevel user
requirements may be needed to be addressed1.
The particular citation in this regard that deserves mention is the business requirement that
empowers the customers with the potentials that eventually facilitates them to withdraw liquid cash
from the ATM. For the successful execution of this entire procedure they are required to perform the
certain functions in the proper chronological order2.
The rules in the event of a business like Open Bravo are the specified business standards, relevant
protocols, guidelines and the relevant practices that have attained success in defining the procedures
of the execution of the business by the users. These protocols must be abided by the software product
to perform accordingly in an appropriate manner in regards to the domain of the concerned
application.
The quality attributes of the user level are efficient in defining the quality of the software product
of the Open Bravo owing to the non-functional characters that are embedded within its infrastructure.
The attributes of the software quality incorporates the characteristics like the availability, reliability,
safety and the security.
B. Business level
1 Alnæs, Martin, Jan Blechta, Johan Hake, August Johansson, Benjamin Kehlet, Anders Logg, Chris
Richardson, Johannes Ring, Marie E. Rognes, and Garth N. Wells. "The FEniCS project version 1.5." Archive
of Numerical Software 3, no. 100 (2015).
2 Muller, Ralf. Project governance. Routledge, 2017.

2SOFTWARE REQUIREMENTS AND SPECIFICATIONS
Within the territorial limits of the business, in our particular case the Open Bravo, the business
requirements are the parameters to define the problems and issues that have crept into the business
scenario and needs to be mitigated 3. The business requirements also address the business
opportunities for the software product. Business requirements clearly illustrates the purpose of
developing the software products to meet the business targets of the Open Bravo. The requirements of
the business are postulated as the customer oriented objectives or in more generalised terms the
request generated by the organization for the software development4.
The particular citation in this regard is the permit granted to the customers for availing the
benefits of cash withdrawal from the ATM. This also enables the customers to undergo transactions at
the petrol pump for availing the benefits of the petrol.
C. Product level
The product level is characterized by the diversified categories of requirements among which the
requirements in terms of functionality, the non-functional requirements, requirements of the external
interfaces and finally the requirements of the data. The functional requirements are the services
rendered by the system5. Non-functional requirements refer to the parameters that impose potential
threats and hindrances in the way of procurement. The requirements in regards to the data refer to the
specified array of the data that are required to be embedded in the software to meet the business
specifications of the Open Bravo.
Illustrate the 3 below mentioned approaches to resolve the volatility issues
of the software requirement:
Involvement of the business side in the project
Alterations in the customer organization
Software projects encounter numerous alterations in their lifecycle. In case of Open Bravo
also, software alterations will affect the customers. The customers of the organization will have to
adapt to the software changes. The customers need to get acquainted to the new updates of the
software and the management is responsible to check that their customers are able to make use of the
updates done without their help. According to the article, understanding requirement volatility is vital
and important. The example of the survey given in the article shows that only 50% of the respondents
had the understanding of requirement volatility.
3 Uhl, Axel, and Lars Alexander Gollenia, eds. A handbook of business transformation management
methodology. Routledge, 2016.
4 Rosemann, Michael, and Jan vom Brocke. "The six core elements of business process management." In
Handbook on business process management 1, pp. 105-122. Springer, Berlin, Heidelberg, 2015.
5 Muller, Ralf. Project governance. Routledge, 2017.

3SOFTWARE REQUIREMENTS AND SPECIFICATIONS
Alterations in the scale
To bring about software alterations Open Bravo needs to face changes in the scale as well.
Changes in the scale include the structural changes that have to be done as per the software
requirement. As per the article the changes in scale include appointing change control boards,
software developers, personnel managing the configuration, contextual management staffs. The
change control boards will be responsible for aligning the staffs towards the software alteration being
initiated6. The software developer will look into the new alterations being made to the software. The
contextual management staff will look after the context being altered and the new context being
implemented. The configuration at present and the required configuration will be checked by the
personnel handling the configuration management department.
External alterations
External changes in a business organization like the Open Bravo refer to the external
parameters or the factors that directly affects the operational procurement of the business. External
factors relate to the ongoing software alterations in the competitive market. The volatility requirement
can be analysed by the same type of software alterations been done to competitor web sites.
New ideas are imbibed within the customer owing to their increasing awareness in
terms of system capabilities
The zeal and the potential that has been encountered within the customers of Open Bravo have
influenced the business performance of the organization that in turn has boosted the involvement of
the business in the concerned project. As per the article the business users should know about the size
of the final value to be delivered in situations where constant change is required as in case of Open
Bravo
Negotiation of the scope of the project
Alterations in the customer organization
Changes in the customer organization influence the negotiation of the project scope by
affecting the discussion with the business users about the potential and the strength of the ultimate
outcome in the event of the constant alterations witnessed in the requirements. As per the article the
volatile requirements of software update projects needs the involvement of the business users thus
Open Bravo should discuss the project details with the stakeholders.
Alterations in the scale
The scaling factor contributes to the operational management by controlling the work-flow.
Hence, the alterations in the scaling factor have greatly influenced the participation of the business in
the concerned project. As per the article, Open Bravo should focus on making decisions relating to
6 Laplante, Phillip A. Requirements engineering for software and systems. Auerbach
Publications, 2017

4SOFTWARE REQUIREMENTS AND SPECIFICATIONS
hiring of workforce for the project. It should decide on the initiation and management of the
workforce hiring process.
External alterations
The external factors like the disruption from the external rivals, the incompetency of the
vendors also has a leading role in terms of influencing the business procurement of Open Bravo. This
will indirectly affect the business involvement in the concerned project. As per the article, in case of
software alterations there is a need to refer to external resources such as domain experts and
knowledge repositories to understand the process7. These can be termed as external alterations as
there are risks of authenticity of the resources and informations.
New ideas are imbibed within the customer owing to their increasing awareness in
terms of system capabilities
This has been found in a generalised survey that the customers of a business are always keen to
develop new and innovative way of thinking that will motivate the organization to render better
services aligned in the line of business growth. This will influence the business involvement in the
concerned project.
Project deadlines rescheduled
Alterations in the customer organization
The change in the customer organization that has been harnessed in any business organization
gradually influences the business operations largely. The deadlines of the project are revised
accordingly8. As per the article, Open Bravo should work according to a specific project plan and
project delivery dates should be rescheduled according to the present status of the project work. This
is a vital aspect of understanding requirement volatility as project deadlines serve as important
parameter in a project.
Alterations in the scale
The scaling attribute is also responsible to control the flow of work and hence has a direct
relationship with the revision of the project deadlines accordingly. The article clearly shows the
dependence of the project on human resources for decision making and other project related tasks.
Human resources deployed by Open Bravo to accomplish the project come under the purview of
requirement volatility as well.
External alterations
The external factors like the competitive advantage and the industrial espionage regulates the
business workflow largely. This in turn affects the rescheduling of the project deadlines in
7 Maalem, Sourour, and Nacereddine Zarour. "Challenge of validation in requirements
engineering." Journal of Innovation in Digital Ecosystems 3, no. 1 (2016): 15-21.
8 Engelbrecht, Jacus, Kevin Allan Johnston, and Val Hooper. "The influence of business managers' IT
competence on IT project success." International journal of project management 35, no. 6 (2017): 994-1005.

5SOFTWARE REQUIREMENTS AND SPECIFICATIONS
accordance. As per the article, requirement volatility in software projects also includes factors such as
using the expert’s knowledge and communications with others having the knowledge of the change
being implemented.
New ideas are imbibed within the customer owing to their increasing awareness in
terms of system capabilities
The zeal and the potential of the customers to explore the newer aspects of the organization like
Open Bravo will eventually control the deadline of the concerned project. The article suggests that the
architecture of the product must be such that the software project can be resilient in volatile situations.
Illustrate the following specifications using sample scenarios:
A. Specifications in terms of state
The attributes and the values possessed by an object defines its state. State specification
clearly depicts the model of the project concerned with the business organization of Open Bravo.
Specifications in terms of state can be well identified with the help of software requirement
documents. Open Bravo can make use of software requirement document to get a better understanding
of the structure for the necessary changes to be done. The IEEE/ANSI 830-1998 can be used that
clearly structures the purpose of the paper, scope of product, definitions, references and overview.
This will Open Bravo to proceed with their work with a definite and organized requirement structure.
The specific requirements relating to functional, interface requirements and non-functional can also be
understood. Common class pattern mode of approach is successful in extracting the classes of the
candidates from the generic class of the objects 9. The approach driven by the users operates in the
following chronological order i.e. search for the account of the customer > identification of the
account type of the customer > checking of the available balance in the account of the customer >
verification of the pin number entered by the customer > dispatching the cash to the customer.
B. Specifications in terms of behaviour
The behaviour specifications of an organization like Open Bravo, is determined based on the
user-defined scenarios. Increment and the iteration of the class are generally witnessed in the user-
based models. The procurement that Open Bravo can opt for occurs in the following chronological
order i.e. identification of all the actors in the array and establishing relationships among them > the
hierarchical order among the use cases are established by the packages of the use cases > the use case
model is graphically represented by the diagrams of the use case > the documentation is exhibited by
9 Ammann, Paul, and Jeff Offutt. Introduction to software testing. Cambridge University Press, 2016.

6SOFTWARE REQUIREMENTS AND SPECIFICATIONS
the formation of the templates. Software requirement document is effective in specifying the functions
needed to be performed, the data to be produced, and results and to whom it may refer to. This can
help Open Bravo to bring in the required changes providing a clear idea what needs to be done.
C. State change specifications
The operational flow of a class is defined by the specifications of the behaviour that
eventually alters the state of the object. This includes the factors that vary during any project. In the
case of Open Bravo, system requirement documents can reflect the changes in the cost, reporting
procedures, schedules and other software development methods in the project.
Assignment 2
Elaborate the 6 risk dimensions by channelizing them in the subsequent 3
groups:
In the process of software development various risks are encountered and thus
managing these risks have become a vital issue. The article considers Bayesian Networks as
an effective tool to manage these risks. The risk involved in software alterations of Open
Bravo can be analysed by the help of this article.
Organizational Environment Risk
Organizational Environment risk involves the changes to the organizational framework that is
necessary for the software alterations to be made. In case of Open Bravo it includes deploying project
heads those who are capable for handling the project. As per the article, organizational environment
risk involves introducing new frameworks for specific project 10. The project will be successfully
completed if the new framework is well adopted by the workforce. This risk can be categorised as
acceptable because when bringing in alterations there is a requirement to change the existing
framework.
User Risk
A project is successful only if its users can connect well with it. As per the article, user risk in
case of Open Bravo can be instances of the users not accepting the software changes, negative
attitude, unwilling to cooperate, conflicts in between users, lack of commitment to the project. This
10 Heikkilä, Ville T., Daniela Damian, Casper Lassenius, and Maria Paasivaara. "A mapping study on
requirements engineering in agile software development." In 2015 41st Euromicro conference on software
engineering and advanced applications, pp. 199-207. IEEE, 2015.

7SOFTWARE REQUIREMENTS AND SPECIFICATIONS
risk can be intolerable for Open Bravo because excessive intervention of the users may disrupt the
project processes.
Requirement Risk
As per the article, requirement risks in case of Open Bravo can be improper system
requirements and system requirements not identified in a proper manner. This risk is intolerable as
before initiating the alterations to the software, the requirements and desired results should be clear.
Project Complexity Risk
The risk factors identified in this case are technical complexities and lack of knowledge of the
technology. Software updates or alterations require good knowledge and the article suggests that it is
a probable risk if not checked. Open Bravo should deploy knowledgeable personnel to bring in the
required software changes11. This risk is intolerable as prior to the initiation experts should be hired
for the tasks to handle the complexities in the project. The level of complexity should be as low as
practicable.
Planning and control risk
As per the article, the risk factors in this case are poor planning, ineffective communication,
and improper estimation of required resources. This is not tolerable as this shows lack of commitment
of the management. The management of Open Bravo should be committed to the project to make it
successful.
Team Risk
As per the article, the risk factors in this case are lack of cooperation and compatibility in the
team members, inexperienced members and lack of adequate training. Team risk should be as low as
reasonably practical as well as intolerable.
Risk detection and removal to combat the 6 risk dimensions:
In order to combat the six risks mentioned above, risk detection and then removing
the same can be used. As per the article, Bayesian networks can be made use of to analyse the
risks involved in Open Bravo’s software changes project. The correlation in between the
recognized risk factors and the associated project outcomes can help Open Bravo to avoid the
risk. The Bayesian network has proved its potential to detect risks and suggest removal
methods. The BN process uses a combination of data along with expert knowledge hence is
effective in detecting risks involved in software development processes. A BN based
11 Heikkilä, Ville T., Daniela Damian, Casper Lassenius, and Maria Paasivaara. "A mapping study on
requirements engineering in agile software development." In 2015 41st Euromicro conference on software
engineering and advanced applications, pp. 199-207. IEEE, 2015.

8SOFTWARE REQUIREMENTS AND SPECIFICATIONS
procedure that makes use of feedback loop can help Open Bravo in prediction of potential
risks so that resolving techniques can be used to resolve the same. The scenario suggests that
the employees are concerned about their own attributes in delivering the outcome for the
customer instead of focussing on the customer requirements. This is a risk factor and hence
needs to be mitigated. The relationships in the project variables can help recognize potential
risk which can then be mitigated by the help of different measures. Association rules help in
finding the rules that are effective in satisfying user-specified support along with confidence
that can help mitigate user risk12. In Bayesian network, the decision trees help in identifying
risks. Open bravo lacks the employee centred infrastructure, it is work centred that is mainly
concerned with the productivity of the organization. This risk needs to be mitigated. Bayesian
networks that are based on graphs and probabilistic theories are popular tools that can visualize
uncertain knowledge performing efficient reasoning at the same time.
Discussion on the formal software specifications to handle the software risk
dimensions
The software risk dimensions that need to be handled in case of Open Bravo are a)
application complexity, b) expertise, c) organizational environment and d) newness of
technology. To handle the above risk dimensions software specification can be used in the
following way:
1. Defining user requirement- This requires capturing and specifying the requirements the
users of Open Bravo expect from the alterations being made to the software. Open Bravo
needs to understand what its users want from the new software13. This can help the
organization in avoid application complexity as it will be user specific.
2. Specifying requirement specification- Open Bravo needs to provide detailed information of
the functionality of the system. This requires deciding what the developers are going to
provide. Open Bravo needs to be clear with its requirements so that the developers can work
accordingly. This will help in maintaining a sound environment in the organization as the
staffs will get an idea of the changes that are going to be done.
12 Maalem, Sourour, and Nacereddine Zarour. "Challenge of validation in requirements engineering." Journal of
Innovation in Digital Ecosystems 3, no. 1 (2016): 15-21.
13 Bonczek, Robert H., Clyde W. Holsapple, and Andrew B. Whinston. Foundations of decision support
systems. Academic Press, 2014

9SOFTWARE REQUIREMENTS AND SPECIFICATIONS
3. Architectural design- This process is effective in identifying and documenting the
subsystems which form the primary system along with the relationship. In order to mitigate
the application complexity risk, Open Bravo can specify the process how the project
requirements need to be met. This is effective in establishing a link in between the design
activities and the requirement activities.
4. Formal specification- This involves using of mathematical notation to define the properties
as well as behaviour of the software system. This will help Open Bravo in mitigating risks
related to expertise. This is considered to be as the first step in software development. The
members not able to understand the first step can surely be substituted with other experts14.
Formal specification will help the software developer of Open Bravo to verify the important
properties before the system development is initiated. It will help resolve ambiguities and
detect errors in the design.
5. High-level design- This provides the overview of the system that is to be implemented
which in turn helps the software developer. Open Bravo can avid risks of newness in
technology by providing an appropriate of the system. The overview will help in organizing
the steps involved in the software development thereby avoiding risks.
In the above way the software specifications can help Open Bravo in handling
software risk dimensions such as application complexity, expertise, organizational
environment and newness of technology.
14 de Vasconcelos, J. B., Kimble, C., Carreteiro, P., & Rocha, Á. (2017). The application of
knowledge management to software evolution. International Journal of Information
Management, 37(1), 1499-1506.

10SOFTWARE REQUIREMENTS AND SPECIFICATIONS
References
Alnæs, Martin, Jan Blechta, Johan Hake, August Johansson, Benjamin Kehlet, Anders Logg,
Chris Richardson, Johannes Ring, Marie E. Rognes, and Garth N. Wells. "The FEniCS
project version 1.5." Archive of Numerical Software 3, no. 100 (2015).
Muller, Ralf. Project governance. Routledge, 2017.
Uhl, Axel, and Lars Alexander Gollenia, eds. A handbook of business transformation
management methodology. Routledge, 2016.
Rosemann, Michael, and Jan vom Brocke. "The six core elements of business process
management." In Handbook on business process management 1, pp. 105-122. Springer,
Berlin, Heidelberg, 2015.
Engelbrecht, Jacus, Kevin Allan Johnston, and Val Hooper. "The influence of business
managers' IT competence on IT project success." International journal of project management
35, no. 6 (2017): 994-1005.
Ammann, Paul, and Jeff Offutt. Introduction to software testing. Cambridge University Press,
2016.
Laplante, Phillip A. Requirements engineering for software and systems. Auerbach
Publications, 2017.
Maalem, Sourour, and Nacereddine Zarour. "Challenge of validation in requirements
engineering." Journal of Innovation in Digital Ecosystems 3, no. 1 (2016): 15-21.
Heikkilä, Ville T., Daniela Damian, Casper Lassenius, and Maria Paasivaara. "A mapping
study on requirements engineering in agile software development." In 2015 41st Euromicro
conference on software engineering and advanced applications, pp. 199-207. IEEE, 2015.
Maalem, Sourour, and Nacereddine Zarour. "Challenge of validation in requirements
engineering." Journal of Innovation in Digital Ecosystems 3, no. 1 (2016): 15-21.

11SOFTWARE REQUIREMENTS AND SPECIFICATIONS
de Vasconcelos, J. B., Kimble, C., Carreteiro, P., & Rocha, Á. (2017). The application of
knowledge management to software evolution. International Journal of Information
Management, 37(1), 1499-1506.
Bonczek, Robert H., Clyde W. Holsapple, and Andrew B. Whinston. Foundations of decision
support systems. Academic Press, 2014.