Use Case

 https://www.visual-paradigm.com/guide/uml-unified-modeling-language/what-is-use-case-diagram/

Software Metrics and Measures

 Software Measures can be understood as a process of quantifying and symbolizing various attributes and aspects of software.

Software Metrics provide measures for various aspects of software process and software product.

Software measures are fundamental requirement of software engineering. They not only help to control the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.” By his saying, it is very clear how important software measures are.

Let us see some software metrics:

• Size Metrics - LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC.

  Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software.

• Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph.

• Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications define the quality of product.

  The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics - In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.

Software System Analyst

 

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the developed software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analyzing and understanding requirements of intended software
• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement
• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders

Notice

 Mid term will for software Engineering and DBMS will be conducted as per schedule:

CA1 for Software Engineering and DBMS will be conducted on 30 October 2020  

Syllabus for Mid term test:

SE: Syllabus for Mid term test: Lectures 1 to 11.

DBMS: Unit 1 and Unit 2

----------------------------------------------------------------------------

Syllabus for CA 1:

SE: Unit 1

DBMS: Unit 1

Characteristics of Good SRS[Software Requirement Specification]

Characteristics of Good SRS[Software Requirement Specification]  

Following are the characteristics of a good SRS document: 

Correctness:User review is used to ensure the correctness of requirements stated in the SRS. SRS is said to be correct if it covers all the requirements that are actually expected from the system. 

Completeness:Completeness of SRS indicates every sense of completion including the numbering of all the pages, resolving the to be determined parts to as much extent as possible as well as covering all the functional and non-functional requirements properly. 

Consistency:Requirements in SRS are said to be consistent if there are no conflicts between any set of requirements. Examples of conflict include differences in terminologies used at separate places, logical conflicts like time period of report generation, etc. 

Unambiguousness:A SRS is said to be unambiguous if all the requirements stated have only 1 interpretation. Some of the ways to prevent unambiguousness include the use of modelling techniques like ER diagrams, proper reviews and buddy checks, etc. 

Ranking for importance and stability:There should a criterion to classify the requirements as less or more important or more specifically as desirable or essential. An identifier mark can be used with every requirement to indicate its rank or stability. 

Modifiability:SRS should be made as modifiable as possible and should be capable of easily accepting changes to the system to some extent. Modifications should be properly indexed and cross-referenced. 

Verifiability:A SRS is verifiable if there exists a specific technique to quantifiably measure the extent to which every requirement is met by the system. For example, a requirement stating that the system must be user-friendly is not verifiable and listing such requirements should be avoided. 

Traceability:One should be able to trace a requirement to design component and then to code segment in the program. Similarly, one should be able to trace a requirement to the corresponding test cases. 

Design Independence:There should be an option to choose from multiple design alternatives for the final system. More specifically, the SRS should not include any implementation details. 

Testability:A SRS should be written in such a way that it is easy to generate test cases and test plans from the document. 

Understandable by the customer:An end user maybe an expert in his/her specific domain but might not be an expert in computer science. Hence, the use of formal notations and symbols should be avoided to as much extent as possible. The language should be kept easy and clear. 

Right level of abstraction:If the SRS is written for the requirements phase, the details should be explained explicitly. Whereas, for a feasibility study, fewer details can be used. Hence, the level of abstraction varies according to the purpose of the SRS.

Classification of Software Requirements

sOFTWARE rEQUIREMENT:- According to IEEE standard 729, a requirement is defined as follows:

•  A condition or capability needed by a user to solve a problem or achieve an objective 
• A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification or other formally imposed documents 
• A documented representation of a condition or capability as in 1 and 2.

A software requirement can be of 3 types:

Functional requirements

Non-functional requirements

Domain requirements

Functional Requirements: These are the requirements that the end user specifically demands as basic facilities that the system should offer. All these functionalities need to be necessarily incorporated into the system as a part of the contract. These are represented or stated in the form of input to be given to the system, the operation performed and the output expected. They are basically the requirements stated by the user which one can see directly in the final product, unlike the non-functional requirements.

For example, in a hospital management system, a doctor should be able to retrieve the information of his patients. Each high-level functional requirement may involve several interactions or dialogues between the system and the outside world. In order to accurately describe the functional requirements, all scenarios must be enumerated There are many ways of expressing functional requirements e.g., natural language, a structured or formatted language with no rigorous syntax and formal specification language with proper syntax.

Non-functional requirements: These are basically the quality constraints that the system must satisfy according to the project contract. The priority or extent to which these factors are implemented varies from one project to other. They are also called non-behavioral requirements. They basically deal with issues like:

Portability

Security

Maintainability

Reliability

Scalability

Performance

Reusability

Flexibility

NFR’s are classified into following types:

Interface constraints

Performance constraints: response time, security, storage space, etc.

Operating constraints

Life cycle constraints: mantainability, portability, etc.

Economic constraints

The process of specifying non-functional requirements requires the knowledge of the functionality of the system, as well as the knowledge of the context within which the system will operate.

Domain requirements: Domain requirements are the requirements which are characteristic of a particular category or domain of projects. The basic functions that a system of a specific domain must necessarily exhibit come under this category. For instance, in an academic software that maintains records of a school or college, the functionality of being able to access the list of faculty and list of students of each grade is a domain requirement. These requirements are therefore identified from that domain model and are not user specific.

 https://drive.google.com/file/d/1QxvGAd60xv5rjUW-3we4UhHr30RLjOsZ/view?usp=sharing