I have recently joined a company and looking after the mobile development projects for both iOS and Droid. The company has no documentation and rely on few expert technical leads sitting on a remote location. The offshore team is trying hard to create SRS and tech specification but it seems its not enough.
There are some inherent issues with the team regarding poor unit testing and also not thinking about the implications of the fixes they provide. Due to lack of overall picture, their fix sometimes breaks other parts.
Please help me out in the requirement management. I feel, we need SRS, Tech specs and RTM. Is there anything else that needs to be taken care of?
What practices should I follow so that the team gains the full business/domain knowledge? Saving Changes...
Sort By:
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Nahid my experience has taught me that traceability is very important. A matrix which helps you tie everything together also helps you understand where it came from, why it is there and how it relates to other requirements. But keep in mind that documentation will not fix a process issue and from what you describe this might be your problem. You need to understand why the unit testing is bad and typically this is not because of documentation but because of a bad or missing process which results in a lack of discipline. When does a change result in regression testing? But having said that one key element that documentation contributes to the testing process is acceptance criteria, this is key to ensuring that the correct thing is tested at the correct level. With clear acceptance criteria, the team does not have to be domain experts but it will help them to get there over time.
...
1 reply by Nahid Ahmed Mansuri
May 14, 2019 3:25 AM
Nahid Ahmed Mansuri
...
Thanks for sharing the thoughts. I too believe that RTM should be the starting point. I discussed with my team and tried to understand their side. One of the key thing is not giving spending sufficient time on unit testing and always in a hurry to commit code without understanding the implications of the changes. I have made them understand that quality is of prime importance. We have also prepared a checklist to ensure all key things are followed before a commit.
Nahid my experience has taught me that traceability is very important. A matrix which helps you tie everything together also helps you understand where it came from, why it is there and how it relates to other requirements. But keep in mind that documentation will not fix a process issue and from what you describe this might be your problem. You need to understand why the unit testing is bad and typically this is not because of documentation but because of a bad or missing process which results in a lack of discipline. When does a change result in regression testing? But having said that one key element that documentation contributes to the testing process is acceptance criteria, this is key to ensuring that the correct thing is tested at the correct level. With clear acceptance criteria, the team does not have to be domain experts but it will help them to get there over time.
Thanks for sharing the thoughts. I too believe that RTM should be the starting point. I discussed with my team and tried to understand their side. One of the key thing is not giving spending sufficient time on unit testing and always in a hurry to commit code without understanding the implications of the changes. I have made them understand that quality is of prime importance. We have also prepared a checklist to ensure all key things are followed before a commit. Saving Changes...
Gaurav DhooperAssistant Vice President| GenpactNoida, U.P., India
This is a practical and usual problem. Please have toll gates or check points implemented in your process to ensure quality control and assurance. This will help in reducing defect leakage drasastically. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
Nahid, you do not need to reinvent the wheel. You have to take a look to IEEE standards. First of all take into account that you have two main roles (roles, then the same person can perform both) and requirements involved: product requirements, business analyst is accountable for that, and project requirements, project manager is accountable for that. From product requirements the project requirements are defined. Both requirements can be managed thanks a common process. Search into the internet the IEEE standards and remember that requirements management is embeded into configuration management standard. Saving Changes...
Nahid, For requirements management (RM), I would suggest you look to the SEBoK, which is maintained by IEEE, INCOSE, and the SERC. It's similar to the PMBoK in nature but the focus is systems engineering (SE).
Documentation alone won't solve your problem. It must be effective documentation, and SE is very focused on effectively describing systems and their functionality. RM plays a big part in that. While I would not suggest trying to become a SE overnight, they have much more comprehensive information how RM is performed, and how it fits in with the rest of the design process. It starts early on, but is ongoing throughout product development. An RTM is one artifact used in RM, but having a matrix itself does not ensure you have good requirements, or verification plans. Saving Changes...
George FreemanThought Leader | Author | Architect| Florida, United States
Nahid,
There are many formal methods available to you, but this sounds like a “knowledge transfer” issue that could still reside even after you implement new standards and methods. Is the knowledge transfer issue related to language, culture, remote context, lack of subject matter expertise on technical side or something else?
When I come upon situations like this, I have done the following:
-- Create a visualized landscape of the application, its components, features/functions and relationship to any life-cycles. This will create a common functional understanding of the product that can be shared between the development team, the leads, and the owners.
-- You should also have a visualized landscape of your application and integration architecture that can be understood by all parties as well.
-- Any changes to the system, also need to be “highly visualized” and put into context of the agreed upon and understood landscapes.
Using highly-visualized approaches can often offset issues when a development team does not have a SME or a SME/Architect on-site who would normally visualize on white-boards anything that was to be done by the team.
So, as you are already planning, implement those standards. But also implement significant visualization standards if you don’t have an embedded SME on the team. Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
Sounds like you are working with a CMMI level 1 (ad hoc) organization. These organizations usually rely on people's experience and skills due to the lack of repeatable processes. It can be difficult to move them away from depending on their "stars".
My suggestion is to try to capture as much documentation as possible as you go along. Be prepared to document the processes for them. It's not fun but it's the only way you can hope to move them up to CMMI level 2 (managed).
...
1 reply by Nahid Ahmed Mansuri
May 14, 2019 11:33 PM
Nahid Ahmed Mansuri
...
Do you have links which guides an org from level 1 to 2? I mean what are the key areas/processes that should be taken care for the transition?
Sounds like you are working with a CMMI level 1 (ad hoc) organization. These organizations usually rely on people's experience and skills due to the lack of repeatable processes. It can be difficult to move them away from depending on their "stars".
My suggestion is to try to capture as much documentation as possible as you go along. Be prepared to document the processes for them. It's not fun but it's the only way you can hope to move them up to CMMI level 2 (managed).
Do you have links which guides an org from level 1 to 2? I mean what are the key areas/processes that should be taken care for the transition? Saving Changes...
Stéphane ParentSelf Employed / Semi-retired| Leader MakerPrince Edward Island, Canada
