ORGANIZATION CHART USING MS VISIO

Step-1:

     Open a Microsoft excel sheet and create the database with three fields namely NAME,POSITION,MANAGER as shown in step 2.

Step-2:

    Now, save the excel sheet with a name.

Step-3:

Now open a new Microsoft Visio file.

Step-4:

Now in the Microsoft Visio file select the "data" option in the menu bar.

Step-5:

There appears a drop down box as shown below figure and select the "organization chart" option in it.

 

Step-6:

After selecting the organization chat option, an drop down box called organization chat wizard appears. You need to select information that's already stored in a file or database option and click next. 

Step-7:

Select the option as shown below and then click next.

 

Step-8:

Now locate the file that contains your organization information and click next

 

Step-9:

Choose the columns(fields) in your data file that contains your information as shown below and then click next.

 

Step-10:

Now choose the column(fields) from your data file that you want to display as shown below and then click next.

 

Step-11:

Now choose the column(fields) from your data file that you want to add to organization chat shapes as shape data fields and click next.

 

Step-12:

Now click the finish option in the dropdown box appears.

 

Step-13: 

Finally we observe the organization chart as shown below for the given created database.

 

Analysis Model

  The analysis model connects the system description and design model. The system description provides information about the entire functionality of the system, which is achieved by implementing the software, hardware, and data. In addition, the analysis model specifies the software design in the form of a design model, which provides information about the software's architecture, user interface, and component-level structure.

In the above figure, the analysis model connects the system description and design model. 

The model should concentrate on requirements in the problem domain that are to be accomplished. However, it should not describe the procedure to accomplish the requirements in the system.

Every element of the analysis model should help in understanding the software requirements. This model should also describe the information domain, function, and behavior of the system.

The analysis model should be useful to all stakeholders because every stakeholder uses this model in his own manner. For example, business stakeholders use this model to validate requirements whereas software designers view this model as a basis for design.

The analysis model should be as simple as possible. For this, additional diagrams that depict no new or unnecessary information should be avoided.

Elements of Analysis Model:

1. Data Dictionary:

It is a repository that consists of a description of all data objects used or produced by the software. It stores the collection of data present in the software. It is a very crucial element of the analysis model. It acts as a centralized repository and also helps in the modeling data objects defined during software requirements.

2. Entity Relationship Diagram (ERD):

It depicts the relationship between data objects and used in conducting data modeling activity. The attributes of each object in the Entity-Relationship Diagram can be described using the Data object description. It provides the basis for activity related to data design.

3. Data Flow Diagram (DFD):

It depicts the functions that transform data flow and it also shows how data is transformed when moving from input to output. It provides additional information that is used during the analysis of the information domain and serves as a basis for the modeling of function. It also enables the engineer to develop models of functional and information domains at the same time.

4. State Transition Diagram:

It shows various modes of behavior (states) of the system and also shows the transitions from one state to another state in the system. It also provides details of how the system behaves due to the consequences of external events. It represents the behavior of a system by presenting its states and the events that cause the system to change state. It also describes what actions are taken due to the occurrence of a particular event.

5. Process Specification:

It stores the description of each function present in the data flow diagram. It describes the input to a function, the algorithm that is applied for the transformation of input, and the output that is produced. It also shows regulations and barriers imposed on the performance characteristics that are applicable to the process and layout constraints that could influence the way in which the process will be implemented.

6. Control Specification:

It stores additional information about the control aspects of the software. It is used to indicate how the software behaves when an event occurs and which processes are invoked due to the occurrence of the event. It also provides the details of the processes which are executed to manage events.

7. Data Object Description:

It stores and provides complete knowledge about a data object present and used in the software. It also gives us the details of the attributes of the data object present in the Entity Relationship Diagram. Hence, it incorporates all the data objects and their attributes.

Differences Between FUNCTIONAL REQUIREMENTS and NON FUNCTIONAL REQUIREMENTS

 

FUNCTIONAL REQUIREMENTS	NON FUNCTIONAL REQUIREMENTS
A functional requirement defines a system or its component.	A non-functional requirement defines the quality attribute of a software system.
It specifies “What should the software system do?”	It places constraints on “How should the software system fulfill the functional requirements?”
Functional requirement is specified by User.	Non-functional requirement is specified by technical peoples e.g. Architect, Technical leaders and software developers.
It is mandatory.	It is not mandatory.
It is captured in use case.	It is captured as a quality attribute.
Defined at a component level.	Applied to a system as a whole.
Helps you verify the functionality of the software.	Helps you to verify the performance of the software.
Example 1) Authentication of user whenever he/she logs into the system. 2) System shutdown in case of a cyber attack. 3) A Verification email is sent to user whenever he/she registers for the first time on some software system.	Example 1) Emails should be sent with a latency of no greater than 12 hours from such an activity. 2) The processing of each request should be done within 10 seconds. 3) The site should load in 3 seconds when the number of simultaneous users are > 10000

 

 

Software Requirements Specification (SRS)

A Software Requirements Specification (SRS) is a document that describes what the software will do and how it will be expected to perform. It also describes the functionality the product needs to fulfill all stakeholders (business, users) needs. A typical SRS includes:

• A purpose
• An overall description
• Specific requirements

The best SRS documents define how the software will interact when embedded in hardware or when connected to other software. Good SRS documents also account for real-life users.

Software Requirements Specification vs. System Requirements Specification

A software requirements specification (SRS) includes in-depth descriptions of the software that will be developed.

A system requirements specification (SyRS) collects information on the requirements for a system.

“Software” and “system” are sometimes used interchangeably as SRS. But, a software requirement specification provides greater detail than a system requirements specification.

Here are five steps you can follow to write an effective SRS document.

1. Create an Outline (Or Use an SRS Template)

Your first step is to create an outline for your software requirements specification. This may be something you create yourself. Or you may use an existing SRS template.

If you’re creating this yourself, here’s what your outline might look like:

1. Introduction

    1.1 Purpose

    1.2 Intended Audience

    1.3 Intended Use

    1.4 Scope

    1.5 Definitions and Acronyms

2. Overall Description

    2.1 User Needs

    2.2 Assumptions and Dependencies

3. System Features and Requirements

    3.1 Functional Requirements

    3.2 External Interface Requirements

    3.3 System Features

    3.4 Nonfunctional Requirements

2. Start With a Purpose

The introduction to your SRS is very important. It sets the expectation for the product you’re building.So, start by defining the purpose of your product.

Intended Audience and Intended Use

Define who in your organization will have access to the SRS — and how they should use it. This may include developers, testers, and project managers. It could also include stakeholders in other departments, including leadership teams, sales, and marketing.

Product Scope

Describe the software being specified. And include benefits, objectives, and goals. This should relate to overall business goals, especially if teams outside of development will have access to the SRS.

Definitions and Acronyms

It’s smart to include a risk definition. Avoiding risk is top-of-mind for many developers — especially those working on safety-critical development teams.

Here’s an example. If you’re creating a medical device, the risk might be the device fails and causes a fatality.

By defining that risk upfront, it’s easier to determine the specific requirements you’ll need to mitigate it.

3. Give an Overview of What You’ll Build

Your next step is to give a description of what you’re going to build. Is it an update to an existing product? Is it a new product? Is it an add-on to a product you’ve already created?

These are important to describe upfront, so everyone knows what you’re building.

You should also describe why you’re building it and who it’s for.

User Needs

User needs — or user classes and characteristics — are critical. You’ll need to define who is going to use the product and how.

You’ll have primary and secondary users who will use the product on a regular basis. You may also need to define the needs of a separate buyer of the product (who may not be a primary/secondary user). And, for example, if you’re building a medical device, you’ll need to describe the patient’s needs.

Assumptions and Dependencies

There might be factors that impact your ability to fulfill the requirements outlined in your SRS. What are those factors?

Are there any assumptions you’re making with the SRS that could turn out to be false? You should include those here, as well.

Finally, you should note if your project is dependent on any external factors. This might include software components you’re reusing from another project.

4. Detail Your Specific Requirements

The next section is key for your development team. This is where you detail the specific requirements for building your product.

Functional Requirements

Functional requirements are essential to building your product.

If you’re developing a medical device, these requirements may include infusion and battery. And within these functional requirements, you may have a subset of risks and requirements.

External Interface Requirements

External interface requirements are types of functional requirements. They’re important for embedded systems. And they outline how your product will interface with other components.

There are several types of interfaces you may have requirements for, including:

• User
• Hardware
• Software
• Communications

System Features

System features are types of functional requirements. These are features that are required in order for a system to function.

Other Nonfunctional Requirements

Nonfunctional requirements can be just as important as functional ones.

These include:

• Performance
• Safety
• Security
• Quality

The importance of this type of requirement may vary depending on your industry. Safety requirements, for example, will be critical in the medical device industry.

IEEE also provides guidance for writing software requirements specifications, if you’re a member.

5. Get Approval for the SRS

Once you’ve completed the SRS, you’ll need to get it approved by key stakeholders. And everyone should be reviewing the latest version of the document.

Problem of Requirements

This is the phase which involves gathering information about the customer's needs and defining, in the clearest possible terms, the problem that the product is expected to solve.

This analysis includes understanding the customer's business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. 

1.Customers don't (really) know what they want 

To solve this problem, you should:

• Ensure that you spend sufficient time at the start of the project on understanding the objectives, deliverables and scope of the project.

• Make visible any assumptions that the customer is using, and critically evaluate both the likely end-user benefits and risks of the project.

• Attempt to write a concrete vision statement for the project, which encompasses both the specific functions or user benefits it provides and the overall business problem it is expected to solve.

• Get your customer to read, think about and sign off on the completed software requirements specification, to align expectations and ensure that both parties have a clear understanding of the deliverable.

2. Requirements change during the course of the project 

To solve this problem, you should:

• Have a clearly defined process for receiving, analyzing and incorporating change requests, and make your customer aware of his/her entry point into this process.

• Set milestones for each development phase beyond which certain changes are not permissible — for example, disallowing major changes once a module reaches 75 percent completion.

• Ensure that change requests (and approvals) are clearly communicated to all stakeholders, together with their rationale, and that the master project plan is updated accordingly.

3. Customers have unreasonable timelines 

To solve this problem, you should:

• Convert the software requirements specification into a project plan, detailing tasks and resources needed at each stage and modeling best-case, middle-case and worst-case scenarios.

• Ensure that the project plan takes account of available resource constraints and keeps sufficient time for testing and quality inspection.

• Enter into a conversation about deadlines with your customer, using the figures in your draft plan as supporting evidence for your statements. Assuming that your plan is reasonable, it's quite likely that the ensuing negotiation will be both productive and result in a favourable outcome for both parties.

4. Communication gaps exist between customers, engineers and project managers 

To solve this problem, you should:

• Take notes at every meeting and disseminate these throughout the project team.

• Be consistent in your use of words. Make yourself a glossary of the terms that you're going to use right at the start, ensure all stakeholders have a copy, and stick to them consistently.

5. The development team doesn't understand the politics of the customer's organization 

To solve this problem, you should:

• Review your existing network and identify both the information you need and who is likely to have it.

• Cultivate allies, build relationships and think systematically about your social capital in the organization.

• Persuade opponents within your customer's organization by framing issues in a way that is relevant to their own experience.

• Use initial points of access/leverage to move your agenda forward.

Feasibility Study

Feasibility is defined as the practical extent to which a project can be performed successfully. To evaluate the feasibility, a feasibility study is performed, which determines whether the solution considered to accomplish the requirements is practical and workable in the software. 

Information such as resource availability, cost estimation for software development, benefits of the software to the organization after it is developed and cost to be incurred on its maintenance are considered during the feasibility study. 

The objective of the feasibility study is to establish the reasons for developing the software that is acceptable to users, adaptable to change and conformable to established standards.

Types of Feasibility:

Various types of feasibility that are commonly considered included are :

•Technical feasibility

•Operational feasibility

•Economic feasibility.

Technical feasibility :

Technical feasibility assesses the current resources (such as hardware and software) and technology, which are required to accomplish user requirements in the software within the allocated time and budget. 

For this, the software development team ascertains whether the current resources and technology can be upgraded or added in the software to accomplish specified user requirements. 

Technical feasibility also performs the following tasks: 

•   Analyzes the technical skills and capabilities of the software development team members.

•  Determines whether the relevant technology is stable and established.

•     Ascertains that the technology chosen for software development has a large number of users so that they can be consulted when problems arise or improvements are required.

Operational feasibility :

Operational feasibility assesses the extent to which the required software performs a series of steps to solve business problems and user requirements. 

This feasibility is dependent on human resources (software development team) and involves visualizing whether the software will operate after it is developed and be operative once it is installed. 

Operational feasibility also performs the following tasks:

• Determines whether the problems anticipated in user requirements are of high priority.

• Determines whether the solution suggested by the software development team is acceptable.

• Analyses whether users will adapt to a new software.

• Determines whether the organization is satisfied by the alternative solutions proposed by the software development team.

Economic feasibility :

Economic feasibility determines whether the required software is capable of generating financial gains for an organization. 

It involves the cost incurred on the software development team, estimated cost of hardware and software, cost of performing feasibility study, and so on. 

For this, it is essential to consider expenses made on purchases (such as hardware purchase) and activities required to carry out software development. In addition, it is necessary to consider the benefits that can be achieved by developing the software. 

Software is said to be economically feasible if it focuses on the issues as:

• Cost incurred on software development to produce long-term gains for an organization.

• Cost required to conduct full software investigation (such as requirements elicitation and requirements analysis).

• Cost of hardware, software, development team, and training.

Requirement Engineering Processes

System Requirement Engineering :

Requirement Engineering Process Inputs and Outputs

Requirement Engineering is the process of defining, documenting and maintaining the requirements. It is a process of gathering and defining service provided by the system. Requirements Engineering Process consists of the following main activities:

Requirements Elicitation:

                   It is related to the various ways used to gain knowledge about the project domain and requirements. The various sources of domain knowledge include customers, business manuals, the existing software of same type, standards and other stakeholders of the project.

                      The techniques used for requirements elicitation include interviews, brainstorming, task analysis,Delphi technique, prototyping, etc. 

              Each of these work products is reviewed by all people who have participated in the requirements elicitation.

• Initiating the Process 

• Facilitated Application Specification Techniques (FAST)

• Quality Function Deployment (QFD)

Requirements specification:

               This activity is used to produce formal software requirement models. All the requirements including the functional as well as the non-functional requirements and the constraints are specified by these models in totality. 

During specification, more knowledge about the problem may be required which can again trigger the elicitation process.

              The models used at this stage include ER diagrams, data flow diagrams(DFDs), function decomposition diagrams(FDDs), data dictionaries, etc.

Requirements verification and validation:

       Verification: It refers to the set of tasks that ensure that software correctly implements a specific function.

             Validation: It refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements.

             If requirements are not validated, errors in the requirements definitions would propagate to the successive stages resulting in a lot of modification and rework.

The main steps for this process include:

The requirements should be consistent with all the other requirements i.e no two requirements should conflict with each other.

The requirements should be complete in every sense.

The requirements should be practically achievable.

Reviews, buddy checks, making test cases, etc. are some of the methods used for this.

Requirements management: 

               Requirement management is the process of analyzing, documenting, tracking, prioritizing, and agreeing on the requirement and controlling the communication to relevant stakeholders. 

This stage takes care of the changing nature of requirements. It should be ensured that the SRS is as modifiable as possible so as to incorporate changes in requirements specified by the end-users at later stages too.