Friday, May 6, 2011
Tuesday, February 22, 2011
Recommended Practices for SRS
SRS stands for Software Requirements Specification. To explain simply, it is the document which specify what are the exact requirements the software would provide.It should be very specific as it is mostly like an agreement because both parties
sign off the document as well.
In almost every organization, there is a standard template for a SRS. The content in it should also be properly defined.A good SRS would provide benefits such as,
- Establish the basis for agreement between the customers and the suppliers on what the software
product is to do :
Since the SRS defines the requirements clearly, it also serves as an agreement. This would also communicate each others' understanding of the requirements.
-Reduce the development effort.
Since the SRS defines the requirements in detail, the developers do not have to spend time guessing or making assumptions.
-Provide a basis for estimating costs and schedules.
The more detailed the requirements are, a more accurate estimate will be able to be provided.
-Provide a baseline for validation and veriļ¬cation.
Once the product is developed, SRS will provide a baseline to as why a certain feature is included / not included as well.
Some other important things to consider while doing a SRS is the internal consistency.(eg: using different words to refer to the same thing).The requirements need to be broken and specified separately as it will bring proper attention to every requirement. Also , another thing is, we need not give too much internal details or go too deep into the technical details unless the client is interested.
sign off the document as well.
In almost every organization, there is a standard template for a SRS. The content in it should also be properly defined.A good SRS would provide benefits such as,
- Establish the basis for agreement between the customers and the suppliers on what the software
product is to do :
Since the SRS defines the requirements clearly, it also serves as an agreement. This would also communicate each others' understanding of the requirements.
-Reduce the development effort.
Since the SRS defines the requirements in detail, the developers do not have to spend time guessing or making assumptions.
-Provide a basis for estimating costs and schedules.
The more detailed the requirements are, a more accurate estimate will be able to be provided.
-Provide a baseline for validation and veriļ¬cation.
Once the product is developed, SRS will provide a baseline to as why a certain feature is included / not included as well.
Some other important things to consider while doing a SRS is the internal consistency.(eg: using different words to refer to the same thing).The requirements need to be broken and specified separately as it will bring proper attention to every requirement. Also , another thing is, we need not give too much internal details or go too deep into the technical details unless the client is interested.
Tuesday, February 15, 2011
Requirements Engineering (1)
One of the main things about delivering the product is identifying the required product. t is also quite important to identify them as soon as possible because the late correction of errors could cost upto 200 times more. Poor requirements is a major source of problems.
Before identifying the requirements, let’s see what requirements are,
• A specification of what should be implemented
• How the system should behave
• Constraint on the development process
• System properties or attributes
Requirements can be classified as the following,
• Functional Requirements- define functionality
• Implementation requirements-how to implement system
• Performance Requirements-specify minimum acceptable performance
• Usability Requirements- specify the maximum acceptable time to demonstrate the use of the system
In eliciting the above mentioned types, it is needed to identify the business / technical stakeholders. Sometimes it maybe difficult to get user input and involvement. In coming to agreements with the requirements it will be easy if the requirements have been put to understandable form. Preparing proper requirements specification with the collected requirements and sticking to them throughout reduces software defects.
The business value of requirements is huge. Unclear requirements may lead to rework and make the project cost unnecessarily large.
Before identifying the requirements, let’s see what requirements are,
• A specification of what should be implemented
• How the system should behave
• Constraint on the development process
• System properties or attributes
Requirements can be classified as the following,
• Functional Requirements- define functionality
• Implementation requirements-how to implement system
• Performance Requirements-specify minimum acceptable performance
• Usability Requirements- specify the maximum acceptable time to demonstrate the use of the system
In eliciting the above mentioned types, it is needed to identify the business / technical stakeholders. Sometimes it maybe difficult to get user input and involvement. In coming to agreements with the requirements it will be easy if the requirements have been put to understandable form. Preparing proper requirements specification with the collected requirements and sticking to them throughout reduces software defects.
The business value of requirements is huge. Unclear requirements may lead to rework and make the project cost unnecessarily large.
UML for the IT business analyst (2)
This is on 4th chapter and the beginning of the 5th chapter of the book.
Howard Podeswa has stressed in those chapters, the importance of interviews. While in practical work life, we hold interviews to gather the requirements, he has stressed that confirming the requirements is more important. This can reduce many costly mistakes which can occur later.
Another new thing that I met while reading the ebook was that he talks about Business Object Oriented Modelling (B.O.O.M)
In different organizations, the system development life cycles differ. One might be using waterfall model while another uses spiral model and so on.But, mostly the phases in these are,
• Initiation
• Analysis
• Execution
• Test
• Close Out
During the Initiation and Analysis sessions, the BOOM occurs. Initiation means getting a rough cut of the business case. In analysis, the detailed requirements are elicited.
In the initiation phase main deliverable is: Business Requirement Document (BRD).Opportunity Evaluation, Project Vision and Scope and Product Vision and Scope are also some deliverables.
The BRD’s main components are business use-case specifications including business use case diagrams, role map , system use-case diagram and initial class diagram, describing key business classes. Howard has presented a detailed template for BRDs which he has advised to adjust according to the project
Howard Podeswa has stressed in those chapters, the importance of interviews. While in practical work life, we hold interviews to gather the requirements, he has stressed that confirming the requirements is more important. This can reduce many costly mistakes which can occur later.
Another new thing that I met while reading the ebook was that he talks about Business Object Oriented Modelling (B.O.O.M)
In different organizations, the system development life cycles differ. One might be using waterfall model while another uses spiral model and so on.But, mostly the phases in these are,
• Initiation
• Analysis
• Execution
• Test
• Close Out
During the Initiation and Analysis sessions, the BOOM occurs. Initiation means getting a rough cut of the business case. In analysis, the detailed requirements are elicited.
In the initiation phase main deliverable is: Business Requirement Document (BRD).Opportunity Evaluation, Project Vision and Scope and Product Vision and Scope are also some deliverables.
The BRD’s main components are business use-case specifications including business use case diagrams, role map , system use-case diagram and initial class diagram, describing key business classes. Howard has presented a detailed template for BRDs which he has advised to adjust according to the project
Saturday, February 5, 2011
Activity Diagrams
Activity Diagrams show the work flow and they should be read from top to bottom.
When most other diagrams focus on objects, activity diagrams focus on activities and how messages are passed in between different activities.
An activity can be defined simply as an operation in the system.
So prior to drawing an activity diagram, it is required that we identify,
• Activities
• Associations
• Conditions
• Constraints
Activity diagrams cannot be matched with the code and are mostly used by business users only.
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan02/t_activityDiagrams_fig1.gif
The above link provides a good explanation of the notations using a simple situation.
When most other diagrams focus on objects, activity diagrams focus on activities and how messages are passed in between different activities.
An activity can be defined simply as an operation in the system.
So prior to drawing an activity diagram, it is required that we identify,
• Activities
• Associations
• Conditions
• Constraints
Activity diagrams cannot be matched with the code and are mostly used by business users only.
http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jan02/t_activityDiagrams_fig1.gif
The above link provides a good explanation of the notations using a simple situation.
Sequence Diagrams
Sequence diagrams are one of the most popular diagram types that are used to analyze and understand a certain solution.Basically speaking , sequence diagrams show the sequence.
UML diagrams can be used to model.
1 Usage Scenarios : This a description of a way a system maybe used.
2.The logic of methods : explore the logic of a certain operation
3.The logic of services : A service is a high level method.The logic of these methods may also be explained using sequence diagrams.
Lets start with the basic elements that need to be used when drawing a sequence diagram.
The above table describes the basic elements that are needed to draw a sequence diagram.
To draw a sequence diagram, we should first understand the scenario / system step by step.
http://www.developer.com/img/articles/2003/09/22/UML/UML0803.gif
The above image shows a sequence digram which is very simple.I have specified the link as well,because the diagram is not very clear.
While looking at the diagram, one thing to notice is,the difference in arrows. (the response arrows are broken lines,and the arrow head is different as well).This is something I used to miss.
UML diagrams can be used to model.
1 Usage Scenarios : This a description of a way a system maybe used.
2.The logic of methods : explore the logic of a certain operation
3.The logic of services : A service is a high level method.The logic of these methods may also be explained using sequence diagrams.
Lets start with the basic elements that need to be used when drawing a sequence diagram.
The above table describes the basic elements that are needed to draw a sequence diagram.
To draw a sequence diagram, we should first understand the scenario / system step by step.
http://www.developer.com/img/articles/2003/09/22/UML/UML0803.gif
The above image shows a sequence digram which is very simple.I have specified the link as well,because the diagram is not very clear.
While looking at the diagram, one thing to notice is,the difference in arrows. (the response arrows are broken lines,and the arrow head is different as well).This is something I used to miss.
Wednesday, January 19, 2011
Short message service center (SMSC)
SMS that we send are stored in a SMSC and sent to the recipient thereafter.When the SMS is sent from the sender's phone, it is first stored in the SMSC. It is a store and forward method that is implemented in the SMSC.
If the recipient is unavailable at the moment, the SMSC should forward the message when he becomes available.If there is a cutoff period defined for the message, at that time the message will be removed from the SMSC.There is a flag to set whether the SMS Sender requires the delivery report or not.
If the recipient is unavailable at the moment, the SMSC should forward the message when he becomes available.If there is a cutoff period defined for the message, at that time the message will be removed from the SMSC.There is a flag to set whether the SMS Sender requires the delivery report or not.
Subscribe to:
Posts (Atom)