Software Analyst

A software engineering analyst serves as a link between the software developers and
the users. They relay the user's needs to the developers and determine the program
requirements. Using their technical knowledge, they assist the developers in setting and
meeting the software specifications based on user information.
Software Analyst Job Duties

A software analyst typically has a wide range of responsibilities, which can

include:

● Analyzing business requirements to determine system feasibility and

recommending improvements
● Testing new releases of software to ensure they meet customer needs
● Creating user documentation to help customers learn how to use
software products effectively
● Evaluating existing systems to recommend improvements or
replacements
● Identifying possible technological solutions to business problems and
recommending them to management
● Performing research to identify new technology solutions for future
problems
● Developing new software applications or adapting existing programs to
meet customer needs
● Maintaining the integrity of databases by creating backup copies and
performing regular maintenance tasks such as updating security
permissions or removing obsolete data
● defining project requirements and developing solutions with
programmers

The interpersonal skills required by a system analyst are:

■ Communication: The analyst needs to be a very good communicator to
understand and communicate to the user group as well as to the1echnical
specialists. Sometimes the users may not be able to communicate their
needs fully to the analyst, but the analyst must be able to understand their
needs from incomplete communication of the users.
■ Foresightedness and vision: The analyst must have foresight and vision,
so that they can factor in the future requirement of the users even if they
have not factored that in the design. The analyst must also have vision with
regard to the technological changes. He/she must be able to predict where
 the business needs and technological capabilities/constraints will be in the
future.
■ Adaptability and flexibility skills: The analyst may be new to the
environment of the particular business but he/she has to be quick on the
uptake and adapt fast to the culture and environment of the organization.
■ Selling: The analyst needs to have flair to sell their ideas and solutions to
the users. Sometimes this may be difficult as the users and clients might
not know what solution will serve them best. The analyst needs to employ
his selling skills to convince the users on the suitability of a solution.
■ Patience and rationality: The analyst needs to be patient and rational so
that he/she do not rush to a solution. If they make haste then they might
miss critical information about the problem/opportunity and end up
promoting a wrong solution for the users.
■ Sound temperament: The analyst needs to remain calm in the face of
adverse situations. Most of the time the critical data that the analyst seeks
is hard to come by and may be late in coming. The analyst will have to put
up with all this and be clam in such situations.
■ Management skills: These skills are an absolute necessity for any analyst.
The system analyst has to deliver in spite of several constraints hence they
must have good management skills to manage time and resources at their
disposal. The particular management skills that they need to have are:
■ Time management skills. This will help them adhere to the
strict schedules of the task.
■ Project management skills. This will help them manage the
project within the boundaries of time and cost.
■ Man management skills. The analyst will need human resource
skills so that they can manage people working under him. This
skill will also help them to connect to people in the client
organization so that there is greater acceptability for their
solutions.
■ Team management skills. The analyst must be a team player.
They have to work in a team and they should ensure smooth
team functioning.
■ Organizing and directing skills. These are basic managerial
skills that the analyst must have to conduct the analysis
properly.
■ Negotiation skills. The analyst should be a good negotiator to
get his way around for the purposes of selling his solution and
to get the relevant data from the client.
 ■ Leadership quality: The analyst must exhibit leadership and take initiative
to understand issues pertaining to the organization and its line of business
in a proactive manner so that they are well aware of the associated issues
of the problem/opportunity as well.
■ Presentation skills: The analyst must have good presentation skills that
will help him to communicate better.

The technical skills required by the system analyst are:

■ Creativity: This skill will ensure that the analyst can give the users novel
technical solutions for the same problem.
■ Problem solving: This skill will help the analyst form a systems approach
to problem solving so that they are able to structure a problem even when
there is none.
■ Technical knowledge: The analyst needs to have concrete knowledge in
the technical domain so that they are able to generate alternative solutions
to problem. Without the technical know how they will not be able to develop
the solution. The analyst must also have a broad knowledge of the entire
technical domain. The broad spectrum of knowledge will help them be
flexible in their solution approach and will ensure that they have a better
understanding of the future of technologies.

What is SRS
A software requirements specification (SRS) is a detailed description of
a software system to be developed with its functional and non-functional
requirements. The SRS is developed based the agreement between
customer and contractors. It may include the use cases of how user is
going to interact with software system. The software requirement
specification document consistent of all necessary requirements
required for project development. To develop the software system we
should have clear understanding of Software system. To achieve this we
need to continuous communication with customers to gather all
requirements.
Software requirement specification (SRS) is a document that completely
describes what the proposed software should do without describing how software
will do it. The basic goal of the requirement phase is to produce the SRS, Which
describes the complete behavior of the proposed software. SRS is also helping
the clients to understand their own needs.

Following are the features of a good SRS document:

1. Correctness: User review is used to provide the accuracy of requirements stated in
the SRS. SRS is said to be perfect if it covers all the needs that are truly expected from
the system.

2. Completeness: The SRS is complete if, and only if, it includes the following elements:

(1). All essential requirements, whether relating to functionality, performance, design,

constraints, attributes, or external interfaces.

(2). Definition of their responses of the software to all realizable classes of input data in
all available categories of situations.

(3). Full labels and references to all figures, tables, and diagrams in the SRS and
definitions of all terms and units of measure.

3. Consistency: The SRS is consistent if, and only if, no subset of individual
requirements described in its conflict. There are three types of possible conflict in the
SRS:

(1). The specified characteristics of real-world objects may conflicts. For example,

(a) The format of an output report may be described in one requirement as tabular but
in another as textual.

(b) One condition may state that all lights shall be green while another states that all
lights shall be blue.

(2). There may be a reasonable or temporal conflict between the two specified actions.
For example,

(a) One requirement may determine that the program will add two inputs, and another
may determine that the program will multiply them.

(b) One condition may state that "A" must always follow "B," while other requires that "A
and B" co-occurs.

(3). Two or more requirements may define the same real-world object but use different
terms for that object. For example, a program's request for user input may be called a
"prompt" in one requirement's and a "cue" in another. The use of standard terminology
and descriptions promotes consistency.
4. Unambiguousness: SRS is unambiguous when every fixed requirement has only one
interpretation. This suggests that each element is uniquely interpreted. In case there is a
method used with multiple definitions, the requirements report should determine the
implications in the SRS so that it is clear and simple to understand.

5. Ranking for importance and stability: The SRS is ranked for importance and stability
if each requirement in it has an identifier to indicate either the significance or stability of
that particular requirement.

Typically, all requirements are not equally important. Some prerequisites may be
essential, especially for life-critical applications, while others may be desirable. Each
element should be identified to make these differences clear and explicit. Another way
to rank requirements is to distinguish classes of items as essential, conditional, and
optional.

6. Modifiability: SRS should be made as modifiable as likely and should be capable of

quickly obtain changes to the system to some extent. Modifications should be perfectly
indexed and cross-referenced.

7. Verifiability: SRS is correct when the specified requirements can be verified with a
cost-effective system to check whether the final software meets those requirements.
The requirements are verified with the help of reviews.

8. Traceability: The SRS is traceable if the origin of each of the requirements is clear
and if it facilitates the referencing of each condition in future development or
enhancement documentation.

There are two types of Traceability:

1. Backward Traceability: This depends upon each requirement explicitly referencing its
source in earlier documents.

2. Forward Traceability: This depends upon each element in the SRS having a unique
name or reference number.

The forward traceability of the SRS is especially crucial when the software product
enters the operation and maintenance phase. As code and design document is
modified, it is necessary to be able to ascertain the complete set of requirements that
may be concerned by those modifications.
9. Design Independence: There should be an option to select from multiple design
alternatives for the final system. More specifically, the SRS should not contain any
implementation details.

10. Testability: An SRS should be written in such a method that it is simple to generate
test cases and test plans from the report.

11. Understandable by the customer: An end user may be an expert in his/her explicit
domain but might not be trained in computer science. Hence, the purpose of formal
notations and symbols should be avoided too as much extent as possible. The
language should be kept simple and clear.

12. The right level of abstraction: If the SRS is written for the requirements stage, the
details should be explained explicitly. Whereas,for a feasibility study, fewer analysis can
be used. Hence, the level of abstraction modifies according to the objective of the SRS.

Properties of a good SRS document

The essential properties of a good SRS document are the following:

Concise: The SRS report should be concise and at the same time, unambiguous,
consistent, and complete. Verbose and irrelevant descriptions decrease readability and
also increase error possibilities.

Structured: It should be well-structured. A well-structured document is simple to

understand and modify. In practice, the SRS document undergoes several revisions to
cope up with the user requirements. Often, user requirements evolve over a period of
time. Therefore, to make the modifications to the SRS document easy, it is vital to make
the report well-structured.

Black-box view: It should only define what the system should do and refrain from
stating how to do these. This means that the SRS document should define the external
behavior of the system and not discuss the implementation issues. The SRS report
should view the system to be developed as a black box and should define the externally
visible behavior of the system. For this reason, the SRS report is also known as the
black-box specification of a system.

Conceptual integrity: It should show conceptual integrity so that the reader can merely
understand it. Response to undesired events: It should characterize acceptable
responses to unwanted events. These are called system responses to exceptional
conditions.

Verifiable: All requirements of the system, as documented in the SRS document, should
be correct. This means that it should be possible to decide whether or not requirements
have been met in an implementation.

Software Requirement Specification

(SRS) Format
In order to form a good SRS, here you will see some points which can be used
and should be considered to form a structure of good SRS. These are as follows
: 1. Introduction
● (i) Purpose of this document
● (ii) Scope of this document
● (iii) Overview

2. General description 3. Functional Requirements 4. Interface Requirements 5.

Performance Requirements 6. Design Constraints 7. Non-Functional Attributes 8.
Preliminary Schedule and Budget 9. Appendices Software Requirement
Specification (SRS) Format as name suggests, is complete specification and
description of requirements of software that needs to be fulfilled for successful
development of software system. These requirements can be functional as well
as non-functional depending upon type of requirement. The interaction between
different customers and contractor is done because its necessary to fully
understand
needs of customers. Depending upon
information gathered after interaction, SRS is developed which describes
requirements of software that may include changes and modifications that is
needed to be done to increase quality of product and to satisfy customer’s
demand.
1. Introduction :
○ (i) Purpose of this Document – At first, main aim of why this
document is necessary and what’s purpose of document is
explained and described.
○ (ii) Scope of this document – In this, overall working and
main objective of document and what value it will provide to
customer is described and explained. It also includes a
description of development cost and time required.
○ (iii) Overview – In this, description of product is explained. It’s
simply summary or overall review of product.
2. General description : In this, general functions of product which
includes objective of user, a user characteristic, features, benefits,
about why its importance is mentioned. It also describes features of
user community.
3. Functional Requirements : In this, possible outcome of software
system which includes effects due to operation of program is fully
 explained. All functional requirements which may include calculations,
data processing, etc. are placed in a ranked order.
4. Interface Requirements : In this, software interfaces which mean how
software program communicates with each other or users either in form
of any language, code, or message are fully described and explained.
Examples can be shared memory, data streams, etc.
5. Performance Requirements : In this, how a software system performs
desired functions under specific condition is explained. It also explains
required time, required memory, maximum error rate, etc.
6. Design Constraints : In this, constraints which simply means limitation
or restriction are specified and explained for design team. Examples
may include use of a particular algorithm, hardware and software
limitations, etc.
7. Non-Functional Attributes : In this, non-functional attributes are
explained that are required by software system for better performance.
An example may include Security, Portability, Reliability, Reusability,
Application compatibility, Data integrity, Scalability capacity, etc.
8. Preliminary Schedule and Budget : In this, initial version and budget
of project plan are explained which include overall time duration
required and overall cost required for development of project.
9. Appendices : In this, additional information like references from where
information is gathered, definitions of some specific terms, acronyms,
abbreviations, etc. are given and explained.

Uses of SRS document:

1. Devlopment team require it for developing product according to the
need.
 2. Test plans are generated by testing group based on the describe
external behavior.
3. Maintenance and support staff need it to understand what the software
product is supposed to do.
4. Project manager base their plans and estimates of schedule, effort and
resources on it.
5. customer rely on it to know that product they can expect.
6. As a contract between developer and customer.
7. in documentation purpose.

Decision Tree in Software

Engineering:
A Decision Tree is a graph that uses a branching method to display all the possible
outcomes of any decision. It helps in processing logic involved in decision-making, and
corresponding actions are taken. It is a diagram that shows conditions and their
alternative actions within a horizontal tree framework. It helps the analyst consider the
sequence of decisions and identifies the accurate decision that must be made.
Links are used for decisions, while Nodes represent goals. Decision trees simplify the
knowledge acquisition process and are more natural than frames and rule knowledge
representation techniques.
Let’s understand this with an example:
Conditions included the sale amount (under $50) and whether the customer paid by
cheque or credit card. The four steps possible were to:

● Complete the sale after verifying the signature.

● Complete the sale with no signature needed.
● Communicate electronically with the bank for credit card authorization.
● Call the supervisor for approval.

The below figure illustrates how this example can be drawn as a decision tree. In
drawing the tree.
Advantages of decision trees
● Decision trees represent the logic of If-Else in a pictorial form.
● Decision trees help the analyst to identify the actual decision to be made.
● Decision trees are useful for expressing the logic when the value is variable
or action depending on a nested decision.
● It is used to verify the problems that involve a limited number of actions.

Decision Table
A Decision Table is a tabular representation of inputs versus rules/cases/test conditions.
It is a very effective tool used for both complex software testing and requirements
management. A decision table helps to check all possible combinations of conditions
for testing and testers can also identify missed conditions easily. The conditions are
indicated as True(T) and False(F) values.

A decision table shows the decision making logic and the corresponding actions taken in
a tabular or a matrix form. The upper rows of the table specify the variables or
conditions to be evaluated and the lower rows specify the actions to be taken when an
evaluation test is satisfied. A column in the table says a rule. A rule implies that if a
certain condition combination is true, then the corresponding action executed.
Links are used for decisions, while Nodes represent goals. Decision trees simplify the
knowledge acquisition process and are more natural than frames and rule knowledge
representation techniques.

Let’s understand this with an example:

Conditions included the sale amount (under $50) and whether the customer paid by
cheque or credit card. The four steps possible were to:
· Complete the sale after verifying the signature.
· Complete the sale with no signature needed.
· Communicate electronically with the bank for credit card authorization.
· Call the supervisor for approval.

Example 1: How to make Decision Base Table for Login Screen

Let’s create a decision table for a login screen.

The condition is simple if the user provides the correct username and password the
user will be redirected to the homepage. If any of the input is wrong, an error message
will be displayed.

Conditions Rule 1 Rule 2 Rule 3 Rule 4

Username (T/F) F T F T

Password (T/F) F F T T

Output (E/H) E E E H

Legend:

● T – Correct username/password
● F – Wrong username/password
● E – Error message is displayed
● H – Home screen is displayed
Interpretation:

● Case 1 – Username and password both were wrong. The user is shown an error
message.
● Case 2 – Username was correct, but the password was wrong. The user is shown
an error message.
● Case 3 – Username was wrong, but the password was correct. The user is shown
an error message.
● Case 4 – Username and password both were correct, and the user navigated to
the homepage

While converting this to a test case, we can create 2 scenarios,

● Enter the correct username and correct password and click on login, and the
expected result will be the user should be navigated to the homepage

And one from the below scenario

● Enter wrong username and wrong password and click on login, and the expected
result will be the user should get an error message
● Enter correct username and wrong password and click on login, and the expected
result will be the user should get an error message
● Enter wrong username and correct password and click on login, and the expected
result will be the user should get an error message

As they essentially test the same rule.

Advantages of Decision Table Testing

● When the system behavior is different for different inputs and not the same for a
range of inputs, both equivalent partitioning, and boundary value analysis won’t
help, but a decision table can be used.
● The representation is simple so that it can be easily interpreted and is used for
development and business as well.
● This table will help to make effective combinations and can ensure better
coverage for testing
● Any complex business conditions can be easily turned into decision tables
● In a case we are going for 100% coverage typically when the input combinations
are low, this technique can ensure the coverage.
Disadvantages of Decision Table Testing

The main disadvantage is that when the number of inputs increases the table will
become more complex

Cost Estimation Models in Software

Engineering
Cost estimation simply means a technique that is used to find out the cost estimates.For
any new software project, it is necessary to know how much it will cost to develop and
how much development time will it take. It is one of the vital processes to start
development for software by considering all internal & external cost factors.

The cost estimation is a tool to estimate the planning, budgeting and resource
utilization for the software projects. Before cost estimation for a software project, we
will have known that what are the actual requirements for a project, what is the
complexity of those requirements, and other cost driver factors that affect the
development (like, product factor, project factor, personal factor& hardware
factor).These are the input to the cost estimation process. So, in general, the process
provides three responses. Such as Effort, Development Duration, and Resources

● Effort: The amount of effort required to complete the development of software

projects in terms of Man-Months (MM).

● Development Duration: The time duration required to complete the development

of a software project i.e. total development time.

 ● Resources: The number of Manpower required for a software project in terms of
time to complete.

But in actually the SCE process follows on cost driver factors i.e. it will affect the
cost of the software. These factors are such as design methodology, memory
management, experienced skills, hardware requirements, software tools, risk
analysis, project complexity, project delay, size of project database, performance
parameter, virtual memory environment, etc.

Software Cost Estimation Models

There is multiple SCE method/model in terms of size or type of project or in static

nature with dependent factors (single parameter or multi parameters). Such as:

1. COCOMO or Algorithmic Model

2. Wideband Delphi or expert Judgment Model

3. Static Single Variable Model

4. Static Multi-Variable Model

5. Estimation by Past Project Model

CoCoMo model : dictated instructive Cost Model (COCOMO)

COCOMO is one of the most widely used software estimation models in the world.
This model is developed in 1981 by Barry Boehm to give estimation of number of

man-months it will take to develop a software product.

COCOMO predicts the efforts and schedule of software product based on size of

software.

COCOMO has three different models that reflect complexity

Basic Model

Intermediate Model

Detailed Model

Similarly, there are three classes of software projects.

Organic mode In this mode, relatively simple, small software projects with a small team

are handled. Such team should have good application experience to less rigid

requirements.
Semi-detached projects In this class intermediate project in which team with mixed

experience level are handled. Such project may have mix of rigid and less than rigid

requirements.

Embedded projects In this class, project with tight hardware, software and operational

constraints are handled.

Each Model in detail

1. Basic Model
The basic COCOMO model estimate the software development effort using only Lines

of code

Various equations in this model are

Where, E is the effort applied in person-months

D is the development time in chronological months and KLOC is the estimated number

of delivered lines of code for the projectn class

Benefit of Web accessibility in software development

Software Engineering plays a fundamental role in the development of accessible

applications, since it can promote the integration between methodologies and specific

accessibility techniques and activities at the software development process

the benefits of incorporating accessibility during the software development process are

greater than the costs involved, as there is an increase in the number of users and value

added to the final product. Additionally, maintenance activities, generally expensive, can

be avoided for inclusion of accessibility.

Computer-Aided Software Engineering (CASE) tools that support the execution of

repetitive tasks, reduce the complexity of development, and improve productivity.can be

used for the web accessibility of the software development.