Semester 2 Alternative Assessment 2020/21

End-of-Module Assignment

Module Code: MS821

Module Name: Applied Systems Analysis

Assignment Title: Semester 2 Assessment

Student Details:

Student ID Programme Student Name Contact Details (Email, Telephone)

(as per registration)
+353 89 941 7062
20234085 M.Sc. ISM ANIRUDH RAO
A.154@NUIGALWAY.IE
I hereby declare that this assignment submission is our own original work. We have read the
University Code of Practice for Dealing with Plagiarism* and are aware that the possible
penalties for plagiarism include expulsion from the University. We have attached a list of all
sources that were consulted in the preparation of this assignment e.g., books, journals, Web
sites etc.

Signature Date

Anirudh Rao 17/05/2021

Contents
Question 1(a) .............................................................................................................................. 3
Question 2 (b) ............................................................................................................................ 5
Question 3 .................................................................................................................................. 9
Definition ............................................................................................................................... 9
Why software Testing is important? ...................................................................................... 9
Types of Software Testing ................................................................................................... 10
Unit Testing ..................................................................................................................... 10
Integration Testing ............................................................................................................... 10
System Testing ..................................................................................................................... 11
User Acceptance Testing ..................................................................................................... 11
Question 1(a):
From the Western Real Estate case study background and interview transcript, answer
the following questions. State any assumptions that you make
1) Critically appraise how well you think Bill conducted the interview. In your
appraisal comment generally on the interview, any shortcomings you can identify
and areas for improvement

Requirements Elicitation or Requirements gathering is one of the most important and key
areas for system development. It is in fact a critical activity and vital process to a project
success (Zowghi D., 2005). Effective elicitation is not only was determined a key factor but
also possible one of the most key areas for Requirements Engineering (Hubert F. Hofmann,
2001). And deficient requirements is the single biggest cause of software failure (Hubert F.
Hofmann, 2001) .
Interviews are known to be one of the most widely used technique for requirements
gathering. This therefore makes them very crucial for the development of any systems let
alone software. They are also the most effective of all the Requirement Elicitation techniques
(Alan M. Davis, September 2006) However, they are quite challenging as they not only
require a mix of technical domain knowledge expertise but a range of soft skills as well. This
is further amplified by the fact that “methodological soundness and correct conduct of
interviews is very important” (M. Bano, 2018) To the effect that not designing the interview
properly or not executing it properly can impact the software and system requirements and
then in turn the software and system design (M. Bano, 2018)
Here, we are exploring the Western Real Estate Case Study in which the interview is being
conducted by system analyst Bill Kennedy whose job is to gather requirements from
stakeholders of Western Real Estate for developing a web-based information system to
support their growth. The interview seems an unstructured one as there are no pre prepared
set of planned questions. However, there seems to be some gaps or shortcomings in the way
the interview was conducted. We wish to explore these here,

No apparent introduction, even as this is a snippet, and we are unable to figure out how
much of an introduction was given beforehand. We have no way of knowing if the ethical
issues were explained beforehand, if consent was taken if the meeting was being recorded etc
An explanation of the goals is necessary as well.

Biased questions. Even as Rachel said that many existing elements will be included in the
“Bear in mind that you have already said that many of the existing elements will be included
in any new Web-based system” current system, for Bill to say “ don’t be afraid to consider
any improvements to the system that you feel are necessary” indicated he had assumed that
new improvements would come on existing systems than try to think that in a new system
existing systems could take a place.

Leading Questions ie., were not typically more designed to find out implicit goals.
Questions were towards a typical direction and not more open ended to identify any further
goals that could exist. This was probably due to the preconceived idea that the system analyst
had and maybe giving a little more open space would have helped to identify. This would
have also helped leverage a certain ambiguity that the system brings in (Beatrice Donati,
February 2017)

Not identifying/communicating with all the stakeholders-Not only did Bill not talk to John
the other partner in the firm, he also did not bring into picture any other stakeholders such as
company employees, investors and all the customers. Talking to all the stakeholders is very
crucial and not identifying all the implicit stakeholders is one of the key mistakes that
students or novices do (Beatrice Donati, February 2017) . This helps in better design of the
system as we are more aware of the requirements.

Interrogative questions- The questions were a little interrogative as in they jumped in from
one question to other without probing deeply into all the requirements of the system. Bill kept
asking from one question to another and should have let Rachel stay and speak to identify the
requirements a bit more. Such as for Sales Request he asked only one question later on and
didn’t enquire if any more requirements were there such as meeting the buyer. Even for
questions relating to agent, Bill could have asked a lot more to help the company.

Suggesting a clue a or Offering Clues – Bill suggested www.irishestateagent.ie to Rachel .

This was outrightly wrong of him to do as he should have offered a few more options or rather
just have gathered requirements and should have offered the options later on. This has impacted
system design in a specific direction, and it’s not known if that’s what is exactly required without
even thinking whether that’s the customer’s exact requirement. An analysis at a later stage is
important.

Verbal communication was required to match Rachel. Even as Bill did do that initially by
saying “Great” and so on, later Bill tapered off and could have used them to simulate the
conversation a bit more and gathered more requirements from Rachel. He could have
complimented and indicated to show he understood such as “I see what you’re doing”. It felt Bill
had already decided and was being abrupt in the later stage of the interview.
 Question 2 (b)
Model the system as specified with the following:
• Two sample UML Use Case Diagrams for important aspects of the system

House showing by agent

House buying
• Two sample Activity Diagrams for important aspects of the system

Processing of offer

Buyer Request
• A sample sequence diagram for an important aspect of the system

Buyer Request
Question 3
(a) Using a variety of sources (e.g. journal/conference papers, Udemy/LinkedIn Learning
videos, case studies etc.), choose 4 different approaches to software testing and describe
how they can be implemented in the development process. You should use examples.
All sources should be appropriately referenced.

Definition
Software Testing is a process of evaluating, verifying to ensure that a software product or
application or platform or service matches the requirements expected of it. It analyses the
existing conditions and compares with expected conditions. Software testing also ensures that
a product is without any defects or bugs. (IBM, n.d.) Software Testing helps identify bugs
early on so that any issues with the software can be solved as soon as possible. (Guru99, n.d.)
This ensures that a “professional delivery” of the software product. Software testing “ensures
reliability, security, and high performance” (Guru99, n.d.).

We can see some of the flaws due to software testing errors or rather lack of it
• In UK, after EDS decided introduce a complex software to Child Support Agency and
at the same time Department of Public Works And Pensions decided to restructure, it
caused incompatibility between the 2 software pieces. This led to 1.9 million people
being overpaid and 700,000 people being underpaid. This cost the UK 1 billion US
dollars. (Harley, n.d.)
• Starbucks had to close around 60 percent of their US and Canada stores due to
software glitches in their POS system. They also had to serve coffee for free for some
time as they could not process any transactions. (Guru99, n.d.)
• In 1996, a US bank lost more than 900 million dollars after a bug in their banking
software caused it credit 823 customers with that amount. (Suhail, 2015)

Why software Testing is important?

1. Cost: Software Testing ensures that money is saved. Cost effectiveness is one of the
most important benefits of software Testing. It in fact costs less to fix a bug. Research
has shown that cost to address bug after release costed $16,000 to rectify but cost to
fix a bug before in the design phase costed only $25. (barnott, n.d.)
2. Security: Security not only helps the product in cases but also ensures personal and
other information is kept safe. Software Testing ensures trust for the product and that
the product functions smoothly later on as well.
3. Product Quality: Software should be as per the expectations of the client or the
product owner. One should ensure it meets the value that it has promised. It is
imperative to meet the quality requirements of a product.
4. Customer Satisfaction: One of the main reasons for building a product is to ensure
that the customers or users are satisfied with it. Amazing software experience ensures
reusability. UI/UX testing is one of the major testing techniques to ensure customer
satisfaction (Guru99, n.d.)
Types of Software Testing

Unit Testing

Unit Testing is a method or a type of testing to ensure that the individual units or modules
present in the system are functioning as per expectations. Each individual module is tested as
a standalone to ensure that the it is functioning correctly and that there are no errors in the
code.
The advantages of unit testing are:
• It’s caught at a very early stage thus reducing the cost of testing defects.
• It improves the design of the code and helps easily make changes. (TutorialsPoint,
n.d.)
• It catches any defects of a new feature.
• The quality of build also improves. (TutorialsPoint, n.d.)

Apart from this there are various code coverage techniques in unit testing these include,
• Branch Testing
• Statement Testing
• Decision Testing
• Condition Testing

There are various tools used by the developer to do unit testing. These include Junit, JMockit,
Nunit etc.

Integration Testing
Integration Testing is a type of testing in which softares modules or parts are combined
together logically to be tested together as a group. (Guru99-Integration, n.d.) Different
modules coded or developed by different programmers are combined and tested in this. The
modules are integrated together usually in top down incremental fashion but also bottom up
fashion also exists. The purpose of Integration Testing is to check and verify that all the
modules are integrating and communicating correctly. It focuses on data communication
between modules (Guru99-Integration, n.d.)
For example, one can test whether 2 microservices are integrating well with each other.
Another example is whether the frontend service is making a call to the back-end service.

Bottom Up Testing : Bottom Up Testing is where first the lower level modules are tested.
The lower level components known as atomic components are integrated together and the
process goes on as we go further up. The Testing only proceeds when the components are
working or communicating properly. This approach helps to identify bugs or defects early on
and saves time and money.

Top Down Testing: In this the control flow of the system is followed and this control flow
hierarchy is what dictates as testing takes place from top to bottom (Guru99-Integration, n.d.)
To check software functionality the higher level modules are tested first and then we move to
lower level modules (Guru99-Integration, n.d.) The advantages of this is it is easier to obtain
an early prototype and critical modules are tested first.

Sandwich Testing: In this Top level modules and lower level modules are tested at the same
time. It is a combination of the top down and bottom-up approach.

System Testing

System Testing is where the complete system is tested. This means the product has been
completely integrated so that the entire system is checked. An end-to-end analysis is
performed in this.

There are various ways of system testing,

Black Box Testing, in this only the input and output of the systems are tested.

White Box Testing, in this each function of the behaviour is tested.

Gray Box Testing, in this tasks risks and assessment methods are tested. (TutorialsPoint,
n.d.)

Load Testing, In this it is tested how software will perform when real life load is applied and
whether it can handle itself in a real life scenario

Regression Testing, in this software system is tested again and again and its verified whether
any changes have caused any bugs to develop.

User Acceptance Testing

This is a type of testing done by test users or clients to verify and evaluate everything is up to
their expectations. This is the final stage of testing and usually done before moving the
software into real life production environment. Business flow is validated in this type of
testing and ensures everything is as per business logic. The testing is done in a real-life
environment which helps validate any environmental or setup changes as well. This testing
helps product users to understand whether they agree with changes as well. Users must have
proper understanding of business requirements before starting this.