Minimal SRS Document

Writing a Requirement Specification Document for a Software Project

A Quick and Easy guide to a Minimal Software Requirement Specification Document

When a problem or solution requiring software is conceived it is essential that the software project is properly conveyed to the software house, agency or project staff creating the software. When constructing the document there are defined standards that the SRS may be structured to follow, such as IEEE Std 830-1998 which has been superseded by IEEE Std 29148-2011.

The document may also be written by the customer should the client choose to do so as it may provide more control of the specifications required in the project. Simply a Software Requirements Specification (SRS) could be titled ;

This is what the customer wants the software to do.

Introduction

The introduction should indicate the expected behaviors of the software as clearly as possible detailing the processes, activities, interfaces, and tasks required by the software. The introduction can be muddied if the software is not already clearly conceptualized or thought out or is to be built onto existing software if the requirements are not understood by all parties. It may also be necessary to indicate the expected life cycle, phase-out period and maintenance required to maintain the performance and usability of the software. Users may also be considered.

Purpose

An SRS document may state the purpose of the software which could be considered an ultimate end-goal of the resulting project and consider the project a failure if not met. It should conclude with affirming that this document specifies how the software should be designed, developed, tested and implemented where applicable. If the purpose is to improve the speed of current business processes then make it appear in the purpose section, if the purpose is to improve the usability of the current software used by staff then include it in the purpose section as well. If the software is also supposed to do something not included in the purpose or easily justified by this section, then it can be hard to justify why such a feature should exist in the project.

Scope

The scope of the document is to provide a description of what the document specification includes, such as use cases and requirements. Some of the program may be in multiple documents so the scope is necessary to reduce overlap between projects.

System Overview

System Overview provides a description of the context, function and requirements of the software project.

References

References should indicate if the software is somewhat pre-existing, any references made in the document and references to appendixes should also be included too.

Overall Description

The overall description is the second section of the SRS document.

Product Perspective

A product perspective is a detailed outlook of what the program should appear like to the users of the system, some software projects may be completely transparent to users, if so then the product perspective should outline the interfacing between other software components that make it so.

  • The overall description should not be vague, it should provide justification as to why the functions of the program are required.
  • The overall description should detail crucial cornerstones of the program and interfaces that exist with the hardware or software.
  • Some of the programs may be pre-existing which will require the project interface detailed and easily readable to be understood.

The Description should have six sections,

  • System Interfaces which the user may interact with the system or the system may interact with other systems.
  • User Interfaces which the users may interact with which may include the frequency of their usage and the intuitiveness of the design.
  • Hardware. Including the frequency of use of the hardware, considerations to the longevity of the hardware and ability to update or dispose of the hardware.
  • Software. Including external interfaces, naming conventions.
  • Communication and Telecom both in interfaces software to software and to the user.
  • Memory. Including minimum requirements.
  • Operations and processes that the program may perform real-time or batch, transaction or otherwise.
  • Adaptations and the ability to configure the system. For open source or high-security systems, this section may be larger than private or closed source software due to the need to ensure that it is secure or can be maintained or made depreciated quickly.

Design Constraints

  • What are the limitations of the software?
  • What might the software fail to perform at?
  • What are the limitations of the programming language if selected?
  • How might this delay the project if risks arise?
  • What are the limitations of the users’ ability?
  • What training will need to take place in order to use the software effectively?
  • What does the software not do?
  • What happens if a user does not use the software as intended?

In most aspects of software engineering, there are simply parts of human nature and failure modes or edge cases that simply cannot always be mitigated, in such scenarios it is important to outline what steps your software has taken to make these issues not slow the productivity of the software and ensure that the system runs as intended part of this may be detailed in test cases written in the appropriate section.

Product Functions

Product Functions should as best as possible describe the function of the program and how the modules of the program if any will work together with the interfaces of the system to produce the software’s desired functions.

The aim of the section is to break down the large characteristics of the program into more readable and manageable sections that can be delegated out to a team or read to an individual clearly without much overlap to avoid confusing what the program is designed to accomplish and what each function does.

  • The functions should be organized and listed so that they may be read for the first time and understood effectively.
  • The section may include graphical sections or UML detailing how the program may operate.
  • The validity of the input.
  • Sequence diagrams or how the program may pass data between functions.
  • How the program accounts for abnormality.
  • Common input examples may be a good way of explaining the function to the reader and providing a sample of what the programmer should accomplish on each function.
  • Sequencing.

User Characteristics

When a user may use the system either from time to time (i.e. infrequently), once or many many times it is important to detail this information in the user characteristics section and account for this in the software, if the methods used to do something are contrived or confusing it could lead to increased mistakes or data mismanagement further down the line and increase the need for normalization or reconciliation of information.

  • User Characteristics should detail the factors that affect each user and provide use cases for each user, it may also be ideal to detail overlapping functions that each user may use and diagram where appropriate.
  • It also may be applicable to detail why each user may need a function of the program.

Specific Requirements

The specific requirements should detail all of the requirements of the clients, the user and the software itself. It should provide suitable detail to enable the software to be written clearly and tested effectively. It should be stated for each requirement which user the requirement is for and if applicable that the test case corresponding to the requirement should be satisfied through cross-referencing other parts of the document.

  • The requirements should be clearly stated to prevent later mistakes or edge cases, poorly written requirements or poorly designed functions may cause the program to be unstable or possibly unsuitable for use. Proper error handling should be given to most aspects of the programs requirement and how it operates to meet the requirement.
  • Vagueness or Failings in test cases may allow for requirements to be deliberately misinterpreted, such as “The program must be fast and easy to use” may be considered easy to use for the programmer or tester, and therefore a suitable statement that the requirement is met, but not for the user who may not understand the inner workings of the software and therefore lack the knowledge to use the software effectively as much as the programmer testing the requirement, it may be a good idea to allow the users to try the functions using agile development and adapting the program accordingly.

The final part of the document should include the appendices and the index.

Exporting GnuCash Data to PowerBi

Some things are better if you do them yourself. I mainly did this project to keep a running ledger of the changes that I would need to keep track of the account balance data.

GnuCash is great, but when I export my accounts data the CSV file isn’t easily translated with power-query automatically. I decided that because I need to keep track of my transactions, this problem was best suited with a little program to calculate my net inflows and outflows using a python program, I also decided halfway through the project that I wanted to hook it up to my graphing backend, a silly idea – but a fun one to see my spends go up and down. I decided that I’d publish it here so that in the future I would find it a lot easier.

Traditionally if you wanted to export GnuCash data from CSV to PowerBi, you’d be better off using their inbuilt power query, however, I wanted to implement a ledger system, something that I don’t think can be accomplished directly in PowerBi without some scripting, and in the future I want to be able to change platforms if I need to because I no longer have a licence for PowerBi or want to use something else like excel or free equivalents like Google Sheets. I reckon that if done properly Google Scripts could make everything run automagically from an upload, but I don’t have my reports ready yet for that to happen.

# Extracted from here https://github.com/aidancrane/GnuCash-CSV2CSV-for-PowerBi/blob/master/convert_to_powerBI.py

import csv
from re import sub
from decimal import Decimal
import time


# If we only want the transactions values, set this to true and they will print to console, they do not save to accounts_out.csv!
numbersOnly = False

# Anyone thats not me will want this to be false, this is used to show the transaction data on a live graph I use for scratching around with.
smoothieChartEmulation = False
sessionCookie = "39494goodluckguessingthispartlololol213232expiresanyway"

# Leave this here so that Notepad++ and Atom auto-suggest it.
# Date,Account Name,Number,Description,Notes,Memo,Category,Type,Action,Reconcile,To With Sym,From With Sym,To Num.,From Num.,To Rate/Price,From Rate/Price

if (smoothieChartEmulation):
     import requests

# Negative Numbers are bracketed when exported from GNUCash so we need to fix that for the float data type.
def convert_if_negative(number):
    returnNumber = str(number)
    if ("," in returnNumber):
        if ("(" in returnNumber):
            returnNumber = returnNumber[1:]
            returnNumber = returnNumber[:-1]
            returnNumber = returnNumber.replace(",", "")
            returnNumber = 0 - round(float(returnNumber), 2)
        returnNumber = str(returnNumber).replace(",", "")
    if ("(" in returnNumber):
        returnNumber = Decimal(sub(r'[^\d.]', '', returnNumber))
        return (0 - round(float(returnNumber), 2))
    return returnNumber

# open accounts.cvs, our exported file.
with open("accounts.csv", "r") as csvIn:
    reader = csv.DictReader(csvIn)
    entries = []

    runningTotal = float(0)
    
	# Save
    for row in reader:
        if (row["Account Name"] == ""):
            pass
        else:
            runningTotal = runningTotal + float(convert_if_negative(row["To Num."]))
            if (numbersOnly):
                print(str(round(runningTotal, 2)))
            else:
                if (smoothieChartEmulation):
                    payload = {'random_graph': runningTotal}
                    r = requests.get('https://dash.infinityflame.co.uk/dash/flex.php', params=payload, cookies={'PHPSESSID': sessionCookie})
                print(str(convert_if_negative(row["To Num."])) + " Description: "+ row["Description"] + " Account Balance: " + str(round(runningTotal, 2)))
                entries.append([row["Date"],row["Description"],row["Category"],str(convert_if_negative(row["To Num."])),str(round(runningTotal, 2))])

# Save what we care about to our new csv for power BI   
with open('accounts_out.csv', mode='w', newline='') as csvOut:
    titles = ["Date","Description","Destination","Transaction","Account Balance"]
    writer = csv.writer(csvOut, delimiter=',', quotechar='"', quoting=csv.QUOTE_MINIMAL)
    writer.writerow(titles)
    for transaction in entries:
        writer.writerow(transaction)

I used python because it’s quick to debug in Atom and I know it well. The way this snippet is used is to export an account from GnuCash, then use this program to output the final CSV to be taken in by PowerBi, I’ve chained these steps together. The final result is stored in accounts_out.csv.

Thanks!

Why Establishing Proper IT Development is Important for the End User

When a project is at its initial planning stages, it is important that the communication between the customer and the IT system’s creator is maintained to ensure that the project is what the customer wants and needs, that the project meets the customer’s requirements and at the same time a list of requirements is drawn up for the customer to confirm, In doing so it ensures that the customer and client have a consistent idea of what the project will do/how it will function. In doing so, errors are less likely to snowball and problems are identified before they are greater than an idea.

Having an open dialogue during development also allows the customer and IT member to have a good understanding of the requirements of the user and what the user is not interested in, this is especially important for systems where the customer will not be the main user for the system, otherwise problems that the customer did not identify may crop up at later stages, which could be costly and time consuming to rectify in non-common IT systems (unlike common IT systems, where a fix may be easier).

Some projects are started and never completed because many projects do not have realistic deadlines, fail to identify the needs of both the customer and the user. fail to identify the needs of the client, are too expensive or are beyond the ability of the person or team making the project happen.

Why effective ICT teamwork is essential to the development of a successful project.

Effective teamwork ensures that every IT member works to their strengths and that they all have a clear idea of what is expected of them and what they need to do next, what others are doing and what is the end result, this ensures that the project is consistent for the end user and customer and works effectively. Failing these crucial steps may mean that some aspects may need to be repeated, the project may not be completed on time or the overall effectiveness of the project is not as good as it could have been. Developing a project also requires following and leaving rigorous documentation for future development of a solution.

Proper IT Development Methodology

Factors that influence the success of an IT development go beyond catering for the end user.

Two factors that are relatively important when developing a project are ‘effective focus of individuals resources and skills’ and ‘effective time scaling and delegation of tasks’.

Effective Focus of Individuals resources and skills ensures that a network manager is not programming the frontend of an application, although he may be able to ‘give a good go of it’ he or she will not be as good as the front-end developer, especially so if the developer has had consistent immersion with the topic.

Effective time scaling and Delegation of tasks ensures that complex problems are not given too little time to work them out, some problems may also require a long time to work out, so need ample time, additionally if a project, like designing a website takes too long. Then other tasks toward the end of a development may not be completed.

Failing to identify the needs of a client may mean that a project is incorrectly understood and could features are mis-implemented or do need meet one of the clients requirements. This could result in numerous users having to resort to time-intensive ways of working around this task or not using the solution. Additionally systems that are not implemented without proper documentation can delay fixing problems.Some problems may also be that developers did not account for backing up the system, so when a project has a failed implementation or data is not backed up when upgrading a system, the data could be deleted due to poor redundancy steps.

The Cheap Raspberry Pi Security Camera

One of the great things about the Raspberry Pi is the community that works to create really great projects. I have setup a Raspberry Pi B looking out my windows. It faces the front door so can see anyone coming down the street and toward the door. I had a couple cheap $2 webcams lying around so I set them up looking out the windows. The total cost of the entire setup is about $10, minus the cost of the Pi itself, I also think that the Pi is a little underpowered for the task as occasionally the thing will stop working after several weeks, the camera still records the video, but the web-interface has to be reloaded in order to get the thing working again.

Capture

IMG_20160418_181953

Overall, I’d say that this project was ineffective for its purpose because unfortunately, the cameras would not record movement accurately enough, and sometimes would record several hours of minimal movement. An IP camera would likely be more cost-effective and better suited for the task, the Pi I used was simply underpowered to monitor two webcams and crashed after about 2 weeks of working continuously. Viewing the files showed that although it captured movement and video, some were corrupt, glitch or only captured about 3 usable frames. It did, however, show a good live view of what was going on outside the house, with about a 4-second delay.

Overall I would say that a Raspberry Pi as a webcam security camera on the cheap is not a good idea, the main contributing factor being that it was not able to keep the program running and often would save garbage to the SD card. If I were to do this again I would not use two for definite as it simply did not work effectively enough to actually increase security, It would often record trees moving for hours and sometimes one camera would freeze up entirely.

Bukkit has been given a DMCA takedown by Wesley Wolfie. The NEXT steps.

It is currently well known that bukkit has been given a dmca request by Wesley Wolfie, but now that that has happened, we now need to rebuild!

So here is whats happening, the folks over from bukkit are now working on a new modding api, called sponge! currently ‘Sponge will start with Minecraft 1.8, with Vanilla Client Support on Forge.’

Old plugins that were written on bukkit will most likely have to be removed, unless someone finds a way to make them compatible with sponge.

Here is a large extract of what they plan to do.

Our ultimate goal is to create a modding API that is easy to use for owners of small servers for friends and family, owners of large servers, and everyone in between. In addition, we also plan to permit client modding.

  • Sponge mods should work across several different Minecraft versions without needing an update from the developer, which means that you don’t have to worry about all your mods breaking between each new major release of Minecraft (1.6, 1.7, 1.8, etc.).
  • Sponge will support official interoperability with Forge so you can use both Sponge mods and Forge mods together. We are working directly with the Forge team.
  • While Sponge will not be directly supporting Bukkit, community projects have been started that aim to provide complete support for existing Bukkit plugins on top of Sponge

the whole plan can be found here

 

Good Luck to you all

 

EDIT, also check out PROJECT RAINBOW, they currently have downloads and plugins up for grabs.